Considering that for tokens I use randomly generated unique strings (not JWT), what the authentication flow should look like in microservice architecture?
What I've come up with so far is the following:
when a user logs in, the backend app sends the provided username/pass to my Authentication microservice
Auth. microservice verifies username/pass, generates token, saves it in its Users db (+associates the token with the current user). Then it returns the token to backend app.
Backend app creates a session (stores it in some in-memory db), saves this token in session, and responds to browser with a cookie.
On every subsequent request user sends cookie > backend app retrieves token from session data > sends it to Auth. microservice which verifies token and grants access.
Is this a solid authentication flow or am I missing something?
Related
Suppose that I have a mobile app with a frontend and a backend server.
My understanding is that -- when a user logs in the app with "Login with google", the frontend sends a request to the google auth server, and gets back an ID token. The documentation says that the frontend can then send the token to the backend server to establish a session. I imagine that means the token can be used in session-based authentication?
If I were to use token-based authentication (as opposed to session-based), do I just attach the ID token in every server request, and have the backend verifies it each time when processing a request? this page suggests the ID token should not be sent to the backend API. Which leaves me wonder what the correct procedure is for token-based authentication when using log in with Google.
So my question is: Does my server need to create an access token from the ID token from Google, and send it to the frontend, so the frontend can attach that access token in the API requests for authentication?
Thanks
Login with Google is an identity provider (IDP) operation. A full OAuth solution, including an authorization server (AS) looks like this:
Mobile app uses system browser to redirect to AS
AS returns a redirect response to the system browser, which routes to the IDP
User signs in at the IDP
IDP returns an authorization code to AS
AS swaps it for IDP tokens and carries out validations
AS issues a set of tokens to the app. This includes an access token (AT) with whatever scopes and claims are needed for business authorization to work.
Mobile app sends AT in API requests
API authorizes using scopes and claims from the access token
So ideally plug in an authorization server, to get this out-of-the-box behaviour. Another option is to implement your own token service, and issue your own tokens. That is less recommended though, since it requires more detailed understanding of the underlying security.
I have a general question on token-based authentication. I've seen multiple guides that seem to say conflicting things, so I'm confused:
Question
Who should be responsible for creating the JWT, the app developer (via the app's backend server) or the auth server (ex. the Identity Provider)?
(1) Here [0], it explains that the developer needs to generate + hash the JWT and use that as the bearer token for any request. From there, the auth server can use the shared secret key to validate the token.
(2) Here [1], it says the auth server generates the JWT and returns it to the client once the login is provided + validated (no backend server involved on the developer's side).
Which one is correct? If they're both correct, how do I know which one to use?
My understanding:
(1) #1 above is one where the developer stores the secret in the backend server of their app. The backen serves as the middle man between the client and the auth server to make authenticated requests without exposing the secret + access token.
(2) #2 above is one where the app has no backend server at all (SPAs like Angular/React). The client interacts with the auth server directly (aka no secrets involved). Per [1], the IdP only uses the client ID, scope and few other things to generate a JWT.
[0] https://enable.cx.sap.com/media/1_uup99qpg (skip to 1:49)
[1] https://auth0.com/blog/handling-authentication-in-react-with-context-and-hooks/ (scroll down to the first block of code under "Add authentication to your app", where the Auth0 instance is configured)
Depending on the project requirements/budget/timeline, the JWT can be created by the developer, or it can be managed by a third party (e.g. Auth0).
Terms
Authentication Server
Receives user credentials (e.g. username & password)
Validates user credentials (e.g. compare username's stored hashed password in the database to the result of hashing the password from the request)
If token is valid, server responds with a token that is used to authenticate future requests (often automatically stored in a cookie in the client by passing it in the proper header in the auth server's response, which can then be automatically included with every request).
Can be written from scratch (allowing for more customization), or can be handled by tools such as Auth0
Scenario 1 (SAP)
This scenario involves making authenticated requests to a third party API.
Your frontend accepts user credentials
Your backend ("authentication server") validates credentials
Your backend responds with a JWT token, created using the RSA Key from SAP, your User ID from SAP, and likely the User ID from your backend server so that you can ensure that the user making a request to authorized to access the data requested. NOTE: Auth0 can be used to create the token, if it supports storing and passing custom values to the JWT
Your frontend makes a request to your backend, including the JWT
Your backend ensures authorization (Auth0 can be used if it supports creating custom logic for checking authorization), then makes the relevant request (based on the request from the frontend) to the SAP server and passes both the JWT and the API Key (stored on your server) with the request
SAP verifies the JWT, and responds to your backend with the requested data
Your backend then passes the relevant data to your frontend
Scenario 2 (Auth0) - YouTube Demo
This scenario uses a third party auth server to authenticate/authorize routes on both your frontend and backend (both of which will leverage Auth0 tooling).
Your frontend directs the user to Auth0's login page
Auth0 redirects back to your frontend, where it stores the JWT
When a user clicks on a button on your frontend that takes them to a different route (e.g. /profile), your frontend can use Auth0 to see if they are authenticated/authorized and extract relevant user data.
When a user clicks on a button on your frontend that makes an API request to your backend, it sends the JWT token with the request, which your backend uses for authenticates using Auth0, and then responds with the relevant data (if the user is authorized to receive it).
How can I have a single JWT token be shared among multiple websites. I assume that the first thing would be to have the same secret on all websites.
If user logs in on site A and a token is generated I want to use the same token for website B on a totally diferent domain.
Can it be done?
What you want can be done, but not with a single JWT token. A JWT token is intended for a certain service or application indicated by the audience (aud) claim. You cannot use the same token for another application or service.
What typically happens to make your SSO scenario work, it that the user logs in to the token issuing (authorization) server. As long as that session is valid, the user can acquire tokens for all applications the server can issue tokens for.
So, when the user logs in to the first application, the authorization server sets a cookie to establish a session. When the user navigates to the second application, the application redirects him/her to the authorization server for authentication. The authorization detects the session cookie and does not prompt to user to log in again, but issues a new JWT token for the second application.
I'm using DRF, and I've enabled Session Authentication so that I can view the browseable API in my browser. In my mobile app, i'm using token authentication. I'm just curious, how does session authentication differ from token authentication in this context? It seems to me that they are more or less the same because with session based auth, a session id instead of a token id is stored in a cookie and used in the same way. Can anybody explain it better?
Sessions and cookies are mainly meant for browsers where the browser will take care of sending the cookie with every request to the server. This why the CSRF protection is only enabled by default for session authentication. On the other hand, token authentication will most probably used with non-browser clients where it stores the auth token and send it with each request in header. This token is not necessarily obtained by exchanging the credentials for a token similar to what happens in session authentication. There can be a use case where an admin generates these tokens and hands it to some other system client that will invoke your API, and clearly this client does not have to have a username and password to exchange it for a token.
The backend for my client web application is a JSON Api. I wanted to keep the backend generic so other devices such as mobile could reuse the same service.
Let's say each user account has a token in their profile, when they login with their username/password I send the token back. In each subsequent request I send back the token, look it up in the database in order to find out who the user is.
As the user moves throughout the app, how/where do I store this token. Do I store it in a cookie? Do I drop an additional cookie in order to keep some kind of session state going?
First of all this is not 100% RestFul.I have faced a similar situation. blogged it here
The solution is, I created a singleton object to store user authentication token in the application container.Then a filter was configured to query the request and get the authentication token sent by the client. Then this token is matched against the token stored in the Singleton Session object.