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)
Related
As the title says, I want to create a RESTful API (stateless) that will access Google API endpoints. First I want to authenticate the user and then use that token provided by Google to access Google Calendar API.
This is the current flow of the app:
Flow
Is there any other way to achieve this since my Nodejs service is signing an already signed JWT token provided by Google (I need to track expiration times for both access tokens)?
I am doing this because I don't want to use Google's access token for my own endpoint authentication.
This is a valid embedded token pattern, where the Google access token is just a custom claim in your own access token.
The client can call your API, using its main token
The API can authorize correctly, based on claims and scopes you have issued for your own data
When required, your API can use the embedded token to get external Google data the user has consented to
Your API should handle 401s from Google APIs in the standard way, as in this code of mine.
Your nodejs service is actually implementing 2 roles here. Consider separating these into a token service and a business service:
Token issuing. A technical job most commonly done by an authorization server.
REST API. A business focused component.
I have an API http gateway (at say https://example.com) integrated with an API REST gateway which uses a Cognito authorizer. All of this to serve a single-page React application. The behaviour is as expected:
I launch the Cognito hosted UI and sign in,
It redirects to the url https://example.com/#id_token=123
If I use PostMan, I can access that url if I pass that id_token in the Authorization header.
Now my question is: how can I pass the header automatically after signing in so I can visit https://example.com?
I have spent a long time on this and have found many similar posts without an answer:
How to use the code returned from Cognito to get AWS credentials?
How can I link cognito token and API authentication header automatically?
AWS Cognito hosted UI returning id_token in URL
How can I make the redirect_uri of AWS Cognito (Hosted UI) authenticated?
Set Authorization header when redirecting client from Cognito to AWS API Gateway
How do I handle a Cognito auth redirect for a Lambda / API Gateway for UI?
We faced the same question a couple of years ago. Our solution was creating a proxy (using API Gateway and Lambda) that "moved" the id_token (stored in a cookie) to the Authorization header for every request to the server. It was ugly, but it worked.
BTW, getting id_token in the URL is how Implicit Grant works. But Implicit Grant is generally considered less secure than Authorization Code Grant. We have since migrated from Implicit Grant to Authorization Code Grant. However, we continue to use the proxy pattern (again using API Gateway and Lambda) as follows.
Exchange the returned code for access_token and id_token at the Cognito user pool's token endpoint. Store the tokens in a DynamoDB table with session_cookie as the partition key. Return the session_cookie as a cookie (with HttpOnly, Secure and SameSite=Strict) to the browser.
For each request from the browser, use the cookie to find the token in the DynamoDB table and put the token in the Authorization header.
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.
i read on this page https://dropwizard.github.io/dropwizard/manual/auth.html that is possibile write a service based on Auth2.0, but i can't understand how can i do this thing.
Someone can help me?
There is a cause, why there are no oauth2 examples. With Oauh2 you have one problem. The way from client to oauth2 server is well defined, but the validation between service and oauth2service can be very custom. Thats why I have written my own Oauth2 Bundle and Oauth2 Service provider for that. So thats why my description below is just theory!
With the link provided by you, it should be easy to implement Oauth2 protected ressources, if you validate the Token yourself.
environment.jersey().register(AuthFactory.binder(new OAuthFactory<User>(new ExampleAuthenticator(),
"SUPER SECRET STUFF",
User.class)));
Then use this annotation
#GET
public SecretPlan getSecretPlan(#Auth User user) {
return dao.findPlanForUser(user);
}
Now you have to implement your Oauth2 authenticator and thats the tricky part, because you have to know your validation server/service. Most of them are different. In most cases you have to take the provided String-Token and then you can verify if the user is registered at the Oauth2 Validation provider.
A short Oauth2 Overview:
Client request a token from Oauth2 service provider (FB, Google,...)
Client send token to your DW app as hhtp Auth header
Your DW app can validate the token against your prefered oauth2 service provider
Oauth2 servide provider checks if the token was released by itself and tells your DW app if token is valid or not and in most cases (like FB) you can get access to the client profile or whatever.
I validate the token against my own Oauth2 service, so this is why my authenticator is very custom and does not help you.
If you want to validate your oauth2 token against, e.g. Facebook, then please read some facebook oauth2 tutorials or any other tutorial or even one for other Oauth2 Validation service providers like Google, Amazon, Instagram ...
If Oauth2 is now to much work for you, why dont you use HTTP basic Auth? In most cases this is all you need for a little DW application.
Here is an example of using Dropwizard Oauth2 with a custom authentication mechanism.
I am new to Fuel PHP... I am working on a project with REST architecture in Fuelphp..... I didn't found any tutorial how to achieve the required functionality "User Authentication using Fuel PHP REST".
As REST server is stateless how do we use auth package of fuelphp in rest api?
As you also pointed, REST calls are somewhat stateless meaning you have no session to store.
The auth documentation has some methods which checks user credentials, but does not store authentication. There are no offical way of doing this.
One of the methods that I have used in the past is to use a token based system. You have an API token linked to an Auth user then this token is supplied in the Authorize header when making a request, the token is then checked against known tokens and if valid a forced login is performed with the Auth package.