OAuth2 for first party web-app

Question

I am building a web (also potentially mobile app) for a platform that allows plugins. We're using the OAuth2 Authorization Code grant type for third-party client plugins.

Which, if any, grant type should I use for our first party clients (i.e. our web/mobile apps)?

Currently, our users log in with an external service, i.e. Google as an OAuth2 consumer. We then issue a JWT (with the username and a CSRF token) as a cookie, and this is used to authorize our users in our API; for third-party clients, we look for OAuth2 tokens.

However, I'm wondering if we should use a 'password' or 'implicit' or 'authorization code with PKCE' grant for our apps so that our endpoints are consistently using OAuth2 for authorization, rather than checking for the JWT (to see if it's a user) and if not checking for an OAuth2 token (if it's a third-party client).

A bit more (possibly unnecessary) detail: we're using the scopes in a GraphQL endpoint to validate queries/mutations and just giving JWT (user) bearers access to all scopes (since a user has access to all their resources from our app). This article seems to suggest I should use 'password' grant type, but I'm a bit confused because we offload our authentication to another provider, so we would just be validating the JWT and then issuing the token, rather than doing anything with username/passwords.

Or should I just issue a token after they authenticate with Google to access resources on our platform (what would flow would this be?). Lastly, and perhaps beyond the scope of this post -- we also want to issue personal tokens so that devs can start working without registering an app using their own data.

Answer 1

You have mainly a session management rather than an authentication issue.

As you noted, users are already authenticated, what you have to decide on is how to maintain the user's session. Issuing a JWT upon Google atuhentication is reasonable choice albeit with non-trivial caveats as a quick search will demonstrate. Instead of a JWT you could rely on HTTP session and cookies - just to present alternatives. IMO you are best off using an infrastructure/library that does this e.g. Spring Security, which you can customize to your needs.

In so far as authorization (access control) is concerned, you noted that users have full access rights. Should that change in the future the nice thing about using a JWT is that it can also contain information about what is in scope. For a more standards based approach I suggest looking at UMA (User Managed Access) libraries/services to build on.

On a side note, using authorization code grant is likely the most secure choice given a third party authentication service is involved - stay with it. Might I also suggest being aware of RFC8252 OAuth 2 for Native apps to ensure authorization code grant is also used properly with mobile apps - it details how redirects/codes are securely managed between the mobile system browser used for authentication and your mobile app.