Token based authentication with Spring and JWT

0
votes

I am using spring security and JWT to implement the authentication/authorization system for my mobile application and I have a couple of doubts regarding the actual design of the system. This is the authentication/authorization flow to allow users to access secured REST APIs:

  1. The mobile application send a request to the /auth/token endpoint, along with the username and password of the user using the basic authentication scheme. The server authenticates the user returning an JWT access and refresh token.

  2. All the subsequent requests to the protected resources represented by the endpoints /api/** are performed passing the access token, which is validated and trusted by the server. The logic to validate and trust the token is performed by a token filter executed before the spring's BasicAuthenticationFilter.

  3. If the token is no more valid the client send the refresh token (JWT) to the /auth/refresh endpoint, which validates this token and if this is trusted returns a new access token. The /auth/refresh endpoint is publicly exposed, but it relies on the fact that the JWT signature must be valid and trusted.

I am also thinking to use OAuth, but I wanted to know if this architectural design can be used or it can be exposed to vulnerabilities or problem with scalability. I am pretty new with the authentication system and I am trying to understand the correct way to implement one without having to use OAuth.

1
javaspringauthenticationjwt

1 Answers

0
votes

What you describe is basically the same as the oauth's password flow except for the missing clientid and secret. The accesstoken and especially the refresh token should NEVER be forwarded to the actual applicaton, whether it's an app or a web application.

Always think in back and front channel. Front channels are where your application is running. Untrusted environments for example mobile phones, client side rendered applications and so on.

These environments could be compromised.
Therefore your accesstoken should always be saved on server side.

But: You don't necessarily need a jwt for described usecase.
If you just need to login, it would be safer to just have a session login mechanism with a csrf validations checks enabled.

However if you want to go with an JWT I would suggest you to go with OAUTH's code flow or to make sure your access token is stored on trusted server side.

For example:

  1. if the user signs in, he get's a session cookie in return.
  2. After that he could also get an such called authCode for a special client (in this case your resourceservers or zuul proxy) and scopes like 'read_profile, make_payments'.
  3. this authCode is now sent to your resourceserver or (zuul proxy sitting in front of your endpoints)
  4. the resource server itself has it's own client credentials and now authenticates against the authentication server and get an accesstoken in exchange to an authcode.

In any case your user would be authenticated session-based on both sides and your resourceserver holds the accesstoken for the user.