CODEWITHSUNDEEP
spring-bootoauth-2.0oauth
erotsppa
erotsppa

Reputation: 15051

Is it insecure to use OAuth access token as a password for JWT sessions in Spring boot?

I'm struggling to find the right architecture for authentication for my SPA applications.

We have

SPA ------OAuth Access Token---> Spring Boot Server
 |
 |
OAuth Authorization Code Flow
 |
\|/
OAuth Provider

The SPA is able to retrieve oauth access token (that only last 24 hours) from this particular OAuth provider. It's not great to have the user relogin every 24 hours so we wish to have the spring server to maintain session with the user for a longer period of time. When our session expires, we are ok to ask the user to authenticate against the OAuth provider again.

This OAuth provider does not offer refresh token.

The SPA once authenticated is supposed to communicate to my spring server to access resources.

I'm not sure what it the best way to maintain session with the spring server longer than 24 hours.

I'm only had experience in the past implementing JWT sessions in spring boot. So my idea is that maybe I can pass the oauth access token to the server and the server can validate the access token, and then if successful, can return a JWT token for longer term session.

Is this approach reasonable? Or is there a better way?

Upvotes: 0

Views: 230

Answers (2)

stringy05
stringy05

Reputation: 7067

It's hard to manage sessions with JWT on purpose - using JWT implies no session against the API as the whole idea of the access token is a stateless mechanism (JWT uses signature verification) for accessing some web endpoint. The libraries, frameworks etc will fight you every step of the way as JWT is not really meant to be used as a session token.

The typical way of managing tokens is for the IdP (or OAuth provider in your diagram) to manage the session via a cookie stored on the browser.

When the access token is nearing expiry, the browser visits the OAuth provider, which coughs up a new access token if the user is authenticated (which in turn is determined via the cookie).

Unfortunately this means you are at the mercy of the OAuth provider. If it wont do sessions and you can't change its behaviour, then you will end up with some hack workaround such as an endpoint to create an JWT access token with an expiry longer than 24 hours, which uses a token from the OAuth provider as authn/z.

Whether or not it's secure will be a matter of debate, but I've seen much worse implementations than that.

Upvotes: 1

Hans Z.
Hans Z.

Reputation: 54038

You should be able to use the refresh grant type to get a new access token, assuming that your Authorization server issues a refresh token, see: https://www.rfc-editor.org/rfc/rfc6749#section-6.

Your suggested approach is reasonable as well but comes close to using a stateful backend for your SPA that handles the OAuth 2.0 flow on its own and issues a session cookie to maintain a session between SPA and backend. The latter is a pattern that is implemented in a few existing server software components out there e.g. mod_auth_openidc

Upvotes: 0

Related Questions