Security implications of using the current session to mint new access tokens
I saw a setup recently where frontend and resource servers were hosted on subdomains of the same second level domain. E.g. ui.example.com and api.example.com. It had an interesting authentication flow that seemed like a variant of the refresh_token oauth grant type, but using a session instead of an explicit refresh_token. I was wondering about the security implications of it, as it seemed smooth and I was considering replicating something like it for my own projects.
I'm assuming from their url structure that api.example.com was actually a gateway that routed to different services, but I don't think that's relevant to the underlying security of the thing.
The flow went something like this:
- user opens ui.example.com/protected
- ui displays a small splash screen and makes POST call to api.example.com/iam/oauth/token with a grant_type of "session"
- This fails as there is no session cookie present
- ui redirects user to ui.example.com/login
- ajax call is made to api.example.com/iam/passwordlogin with creds the user entered
- credentials are validated and a session is created. The response sets a Secure;HttpOnly;SameSite=Strict cookie with the session id.
- user is redirected back to ui.example.com/protected again and this time the call to api.example.com/iam/oauth/token with a grant_type of "session" succeeds, it responds with a very short-lived JWT in the response body which the UI keeps in memory and uses to call other resources on api.example.com via the Authorization header.
- When the ui is about to make other calls to api.example.com, for example api.example.com/myresource/, it checks the JWT in memory and if it is expired/about to expire/missing it makes another call to the api.example.com/iam/oauth/token with the grant_type of session to retrieve a new one. It stores that new one in memory and uses it to make the call.
This seems like an interesting variant on the refresh_token flow to me, using the existing session in a cookie instead of passing an explicit refresh token. It makes the process particularly smooth for the UI, while still allowing the api.example.com/iam/oauth endpoints to offer all the other grant_types needed for other kinds of clients other than the first party browser client. I'm assuming that the reason they didn't want to just pass the session token all the time was to simplify CSRF protections for the api and to allow an api to only need authentication via the Authorization header. Only the service that is accessed at api.example.com/iam/ needs to know about cookies.
I was going to replicate it for a project I'm working on, but couldn't think if there were any security considerations that hadn't already been mitigated. For example, CSRF is mitigated by it being a samesite=strict cookie for the session token. XSS is always a concern, but the access token is stored in memory on the client and very short-lived and javascript cannot access the session token.
Other than it being quite non-standard using cookies for a variant on the refresh_token grant_type, am I missing something that would make this inherently insecure and therefore not a pattern I should make use of?
