Do you store JWT tokens in db ?

[tangara goh]

Hi experts,

I am self-learning the JWT and OAuth since I didn't get to do it in my last temp job.

There is a java brain youtube video that teaches the JWT and then using Postman to see the bearer.

Although I have read countless in the internet but I feel that it is always not complete.

At the back of my mind, I just wonder if the JWT tokens with its expiry date are stored at all?

And also after the JWT token is verified, how is the User being transported to a 3rd party that is using OAuth2 ?

Furthermore, how does it take place in a AWS setting?

Hope someone can kindly advise me on the above.

Tks.

[Stephan van Hulst]

You probably didn't get a full story because there isn't a full story. OAuth is a standard with a very high abstraction level, it leaves a lot of implementation details to authentication providers. For instance, OAuth says nothing about JWT tokens. JWT token are just one of the many ways you can implement data exchange between hosts.

JWT tokens come in different flavours. Transparent JWT tokens contain information like the user ID that was authorized. When you're using these you don't have to store any tokens anywhere, in theory. Your server just validates the token, checks that it hasn't expired, and then does with the user ID from the token what it wants. The client could theoretically request a new token before every request and nothing would get stored. It's common for the client to save the token in a cookie or user session though.

Opaque tokens don't contain information that is accessible by the web service. The web service must present the token to the authentication provider that generated the token, which will then validate the token and return a user ID or other info back to the web service. In this case, the authentication provider must store data that's associated with the token. It may still store data in the token itself, but it will encrypt the token to make it unreadable to anyone but itself.

tangara goh wrote:And also after the JWT token is verified, how is the User being transported to a 3rd party that is using OAuth2 ?

If the web service validates a transparent token, the user info will be present in the token itself.

If the token is opaque, it must be traded for user information with the authentication provider.

Furthermore, how does it take place in a AWS setting?

What exactly do you want to achieve?

[tangara goh]

Stephan van Hulst wrote:JWT token are just one of the many ways you can implement data exchange between hosts.

JWT tokens come in different flavours. Transparent JWT tokens contain information like the user ID that was authorized. When you're using these you don't have to store any tokens anywhere, in theory. Your server just validates the token, checks that it hasn't expired, and then does with the user ID from the token what it wants. The client could theoretically request a new token before every request and nothing would get stored. It's common for the client to save the token in a cookie or user session though.

Opaque tokens don't contain information that is accessible by the web service. The web service must present the token to the authentication provider that generated the token, which will then validate the token and return a user ID or other info back to the web service. In this case, the authentication provider must store data that's associated with the token. It may still store data in the token itself, but it will encrypt the token to make it unreadable to anyone but itself.

tangara goh wrote:And also after the JWT token is verified, how is the User being transported to a 3rd party that is using OAuth2 ?

If the web service validates a transparent token, the user info will be present in the token itself.

If the token is opaque, it must be traded for user information with the authentication provider.

Furthermore, how does it take place in a AWS setting?

What exactly do you want to achieve?

Thanks Stephan.

Say if I use JWT and check against a User role before he/she has access to a resource endpoint.

Will it be ok if the token and secret being shown in the client's browser end ?

I am totally confused how the flow of things. After a User is verified by Spring Security JWT module correctly, how is OAuth2 come into the picture ?

The user will be re-directed to a OAuth2 server for another authentication ?

Hope you could advise me.  Many thanks again.

[Stephan van Hulst]

tangara goh wrote:Will it be ok if the token and secret being shown in the client's browser end ?

I don't know what you mean by this. What secret are you talking about? And why would you want to show a token in the browser? Once the application client has a token from the authorization server, they just include it in every request to the resource server. There's nothing else the client should do with the token.

After a User is verified by Spring Security JWT module correctly, how is OAuth2 come into the picture ?

Token validation is part of OAuth. You start doing OAuth the moment the client asks for a token to access the resource server with, and OAuth ends once the resource server has validated that the user is authorized to access the requested end point.

I am totally confused how the flow of things.

OAuth has different flows, depending on your type of application and who needs to access it. Typically you will want to use the Authorization Code Flow:

The client (meaning the application that runs in your browser, NOT the user and NOT the browser itself) will ask the authorization server (NOT your application server) for an access token to access the resource server, if they are not already logged in.

The authorization server will redirect the browser to a login page where the user can enter their credentials. After the authorization server has validated these credentials, an authorization code is generated and the browser is redirected to a predetermined URL where the application server (or maybe client) will swap the authentication code for an access token. This access token can be stored in the secured user session.

The client now has an access token which it will include in the request to the resource server to perform the actual action that they are interested in.

The resource server validates the access token, either directly by using a trusted certificate from the authorization server (if the token is transparent), or they send the access token to the authorization server which will validate the token and return a user ID.

Once you have a user ID, OAuth is done and you can continue with the rest of your request.

This entire process is OAuth.

The user will be re-directed to a OAuth2 server for another authentication?

There are 3 servers involved: The authorization server, the application server and the resource server. Usually, the application server and the resource server are really the same server, because the server that hosts your client is also the server that will handle requests from the client.

The authorization server is typically not written by you. It's a third party service such as Facebook or ADFS. You must register your application with the authorization server before they will send you authorization codes and access tokens.

The application server/resource server IS written by you, although the resource server may also be a third party service (such as when your application uses your Facebook profile).

ALL servers I mentioned are involved in OAuth. The entire process is called OAuth. There is not a single "OAuth server".

[tangara goh]

Stephan van Hulst wrote:

tangara goh wrote:Will it be ok if the token and secret being shown in the client's browser end ?

I don't know what you mean by this. What secret are you talking about? And why would you want to show a token in the browser? Once the application client has a token from the authorization server, they just include it in every request to the resource server. There's nothing else the client should do with the token.

For example, we can obtain a key and token from site like Github which provide a OAuth2 feature and developer can use as a sandbox.  As a user, you can see the key and secret.

Isn't that the same as showing the token and secret to the client browser?

Because all along I also thought that the Secret Key and token it is not supposed to show, after the user log in with the right user name and password.

However, I am still very much confused.  Will JWT layer be needed if after that the user is re-direct to another site, for example, and is that when the OAuth2 comes into the picture ? and only when this layer of security is passed then the user will be able to go to another site and can go back to the home back as needed.

[Stephan van Hulst]

tangara goh wrote:For example, we can obtain a key and token from site like Github which provide a OAuth2 feature and developer can use as a sandbox. As a user, you can see the key and secret.

Be careful with the terminology. When you register your application, Github will display a client ID and client secret. These are NOT the same thing as an authorization code or access token.

Client IDs and client secrets are used to authenticate your application, not the user that uses the application. This is necessary because identity providers (Github in this case) will not allow a user to log in if it doesn't trust the application that the user uses.

Of course Github will display these values to you, the developer (not the user), because how else would you be able to configure your application? Note though that many identity providers will only display the secret once, when you register the app. If you don't write the secret down and you forget it, it's gone forever and you have to re-register your app.

Isn't that the same as showing the token and secret to the client browser?

No. Client ID and client secret by themselves are not enough to authenticate a user. You use the client ID to identify your application after which the user is redirected to a login page. After the user enters their credentials, an authorization code is sent to your application server. Your server uses its client secret to swap the authorization code for an access token. Then your server may store the access token in a secure user session.

While the client ID and client secret may be shown to the developer in the Github control panel, the authorization code is only used by your application server and the access token is only stored in the session. The client never displays the token.

Another thing: just because Github will temporarily show you the client secret, as its name implies, you must keep it secret! This also means that you may not send the secret from your server to the client. Swap the authorization code for an access token on the server side. If another person gets your secret, they can spoof your application and let users do stuff they didn't intend.

Will JWT layer be needed if after that the user is re-direct to another site

JWT is just a standard for formatting information. It can be used for other purposes than OAuth, and OAuth can also work using other formats than JWT.

The access token that is sent from the identity provider to the application server is often in JWT format, and it usually stays in the same format when you store it in the user session.

is that when the OAuth2 comes into the picture ? and only when this layer of security is passed then the user will be able to go to another site and can go back to the home back as needed.

Like I said in my previous post, everything you do related to authorizing your application is OAuth. Registering it is part of OAuth. Redirecting the user to a login page is OAuth. Swapping the authorization code for an access token is OAuth. Using the access token to access a service endpoint is OAuth.

OAuth doesn't just stop after the identity provider has given you an access token. Every time you call a protected endpoint, you must retrieve the user ID. Whether you do this by getting it from the cached access token or whether you make another call to Github, it's all OAuth and happens at the start of every request.