We are developing our Chat Bot using Actions on goole SDK. On Console in Webhook section in our chatbot we are using HTTPS endpoint as fulfillment method. Now we want to secure our Webhook url endpoint, what are the ways we can use to secure our webhook url endpoint?
Requests from Google to your webhook have a google-assistant-signature header which contains a JWT.
If your fulfillment is built using the Node.js library, the verification is built in with a single line:
const {conversation} = require('#assistant/conversation');
const app = conversation({verification: 'nodejs-cloud-test-project-1234'});
// HTTP Code 403 will be thrown by default on verification error per request.
If it doesn't use that library, you'll need to look for a JWT compatible library for your language/runtime and check that the audience field of the coded JWT matches your project. The linked documentation provides more context.
Related
I've been exploring utilizing Cognito User Pools for authentication and API Gateway to feed client requests with auth tokens. I'd basically like to have a simple react app that utilizes the cognito sdk for authentication. Then use the authentication to make requests via the API Gateway to an express application, hooked up to cognito user pool auth. It would be ideal to have user information available in the express app - seems pretty simple to me.
I've seen many articles and forum posts about how to retrieve Cognito User Info in the context of a lambda function but nothing about how to retrieve Cognito User Info in the context of an HTTP Integration.
Is this possible?
Yes, it is possible, and can be achieved in, at least, two ways:
Proxying requests with original headers
If you enable "Use HTTP Proxy integration" in your HTTP integration, the API Gateway will act as a proxy and forward any headers in the request to the backend (and same from the backend response back to the client). This means that the JWT will reach the express application in the same header the client sent it, where it can be decoded and the claim(s) retrieved.
Using request [and response] data mappings
Another way is to pass the required claim(s) in the Path/QueryString/Headers mappings for the Integration Request, using context.authorizer.claims.{claim} in the mapping, e.g. context.authorizer.claims.email. You can see the documentation on setting up the data mappings and also the mapping reference for more variables that can be used. Please note that for context variables the right syntax to use is without the $ prefix.
Question
I got a problem with understanding some basic thing about auth0, probably someone can help me out.
In the tutorial SPA + API one of the first lines in the TDLR is this:
Both the SPA and the API must be configured in the Auth0 Dashboard
I dont understand why I need to configure the API on Auth0. My code seems to work so can anyone help me understand if I do something wrong or what the advantages are if I actually add a custom API in my dashboard?
Setup
SPA (React)
Auth0
REST API (ktor)
What I do
Created a SPA on Auth0
Login on my SPA through Auth0 to get a JWT (google token)
Sending the JWT as authentication bearer in my calls to the REST API
REST API verifies the JWT token with a JWK provider using the Auth0 url mydomain.eu.auth0.com/.well-known/jwks.json.
Authentication seems to work
Great question, I am assuming that your authentication request includes audience parameter which represents your custom API(Rest API)right now. In oauth2 terms, it is called Resource Server. Each resource server can have many permissions which you include in the scope when initiating the authentication request. Let's step back and talk about the token format. Auth0 issues token in two formats:
Opaque strings: When not using a custom API
JSON Web Tokens (JWTs): When using a custom API
https://auth0.com/docs/tokens/reference/access-token/access-token-formats#how-does-all-this-affect-the-token-format-
As explained above link, the token format depends on the audience (Custom API) parameter. Therefore, when the authentication request includes audience, auth0 issues JWT token with all necessary permission. Then, you need to validate the JWT token in your API server before returning the resources to your front end client.
It should make sense why you need to create custom API in auth0 and define permissions. If you do not create custom API in auth0, there is no way to know what kind of permission you need in the token which will generate an error(invalid audience specified)
We have a Web App using REST API. The REST API is based on Loopback and uses it's built-in token-based authentication. For the Web App we use forms based authentication over HTTPS, so the user has to enter his username and password which we then use to get access token from the REST API via POST /users/login endpoint.
One of our customers asked us to support single sign-on (SSO) authentication through SAML 2.0 and AD FS.
We configured our Web App as a service provider (Relying Party in AD FS) and managed to support SSO for it. The changeling part is the authentication between Web App and the REST API. The idea right now is to configure both Web App and the REST API as the same Relying Party and add new POST /users/saml-login endpoint to the REST API, so the Web App can send a SAML response to that end point and get an access token based on the claims specified in the SAML response. Everything else should work as it used to work before. Here is the flow I imagine:
Web App generates SAML request and redirects a user to the IdP login page
After a successful login the user is redirected back to the Web App with the SAML Response
Web App acts as a proxy and redirects the SAML Response to the REST API endpoint (POST /users/saml-login) where it is validated
If the SAML response is valid the API returns an access token based on the claims
Web App uses access token for further communication with the REST API same as before
Here is the question: Is it OK to implement SAML-based SSO this way? Do you see any issues or security considerations with this approach? Are there any alternatives?
I have read a lot of articles on the web and questions here on StackOverflow about how to use SAML & REST API together:
Propagate SAML Assertion Response/Security Context to downstream Services/Apps
REST API authentication with SAML
SAML and back-end REST service authentication
Attacking SSO: Common SAML Vulnerabilities and Ways to Find Them
None of them really helped me to confirm or reject the idea described above.
That sounds like a reasonable approach. I can't think of any security issues.
You're simply re-posting the SAML response internally within your application for processing. As long as you then perform the various security checks on the SAML response and assertion within your REST API, there shouldn't be any issues.
I have written a web application which makes REST API calls to a message broker. The message broker contains already written REST APIs to which can be used to get message broker data. The message broker is written in a way in which each REST API call sends the user name and password which is encoded with base64. I need to make a login to my web app and authenticate it with OAuth.Does anyone know how to do this? How to authenticate the REST APIs with OAuth?
Step 1: Add OAuth 2.0 to your web server. This is very standard with lots of libraries available. You did not specify the Identity Provider that you will use (Google, Facebook, Auth0, Okta, etc), but each vendor has documents and libraries for you to use in your desired language.
Step 2: Add an Authorization Header to your API calls. The standard method is to add the HTTP header Authorization: Bearer access_token when making an API call.
Step 3: Add OAuth token verification to your API. When your API receives a request, it extracts the Authorization header and verifies the Bearer token. How this is done depends on the Identity Provider. For example, some vendors provide a Signed JWT (which you verify with the vendors public certificate), others provide an opaque access token (which you verify by calling the vendor's token endpoint). Add internal caching of tokens so that you don't need to verify on every API call.
If you understand OAuth 2.0 the above steps are straightforward to implement. If you don't Oracle has a set of videos which are excellent for getting started understanding OAuth.
Oracle Cloud Primers
If your desired OAuth implementation does not require users logging in and is a server to server service that you control on both ends, then you can use just part of OAuth which is Signed JWT (JWS). You create a Json data structure with your desired content and sign it with a private key. This creates a token that you can use in the above steps. You would then validate the token using your public key. You can use self-generated keypairs generated by OpenSSL or similar products for your signing and verification.
What would be the actual solution to build a server with Grails and Spring Security that meets the following requirements :
Access to the server would be restfull, so only by third party clients (mobile,...)
The authentication would use the oauth2 facebook services and the client would use a facebook SDK to provide a token to the server
The authentication would be on per request basis so the token would be passed on the request as GET parameter (not POST as the Rest API uses it)
No need to access Facebook user's information, only authentication
I tried Spring Security Facebook but the Json filter only returns user details so no per request or per session authentication.
I noticed Spring Security Oauth2 Provider but to me it's a provider and not a consumer that could plug into another provider like Facebook so no clue on how to use it.
Spring Social doesn't seem to meet my requirements.
As a result of this search for information, I intend to write a plugin to create a Restfull server connected to facebook.
Thanks in advance
You could implement a security filter on the top of all your requests, and then if the request contains an auth header for the API you respond with as a restful API, otherwise you redirect your users to the login page, handled by the oauth authentication service, where you let the users login with the oath method (facebook, mozilla persona or whatever you like)