Search code examples
oauth-2.0google-oauthopenid-connectspring-security-oauth2google-identity

How to build your OAuth flow when using Google id token?

My client(front-end) is a native mobile app (built with Flutter). For the backend, I'm using Spring to expose resources via Rest API endpoints. I want to implement Google Sign-In for my application. Also, I want to use OAuth flow for my own end points.

I found overall flow recommended for this situation Authenticate with a backend server. So as I understood the process is like this:

I use google sing in my native app and it receives token when user signs in, then the app send it to my authorization server(AS). Then AS just directly sends access (+ refresh) token to the app(i.e client). We can say that it is a password grant type, but instead of using user and password to identify user, AS uses token which we received from google. And when the app calls my Resource server(RS) it uses access token issued by my AS. am I right? PS I draw some diagram showing this flow:

[https://drive.google.com/file/d/1mvB6InwLAJeVe8DRqPFodyPRAz6lzUhK/view][2].

In summary, the question is how to build your Oauth flow when you receive google token id? is using password grant type recommended for this situation? Does it make sense using authorization code flow, considering that my client has already received id token?

Solution

  • The preferred option if your Authorization Server (AS) supports it, is to do this, which should require zero code changes to your app:

    • Your app only connects to your own AS and only uses tokens from your AS - it is standard for your app to use Authorization Code Flow (PKCE)

    • The AS redirects to Google and also handles the response, swapping Google tokens for AS tokens, which are then returned to the app

    This won't work if you use the Password Grant however, since this flow does not support federation. If it helps, my visual blog post has more info on this design pattern.

    GOALS AND TRADE OFFS

    • The User Experience should be the same whether or not you use federation
    • Future Extensibility is worth thinking about - the pattern I describe generally gives you the best options if you want to integrate 3 other login options in future
    • Technical Simplicity for your UIs and APIs is also worth thinking about - how much code complexity are you adding?

    Unfortunately, the technology is often imperfect. I hope at least my comments help you to understand the goals behind the OIDC standards.

    YOUR CODE AND THE LIBRARIES YOU USE

    I would be a bit careful in this area. The link you referred to is very Google specific and focused on calling Google APIs to get Google data. If this is your goal then that is fine, but it may limit you if you also want to do non Google stuff.

    The code samples on my blog are focused on being OIDC standards based, which starts with using standard messages. This gives me the best future options, via AppAuth libraries. It is not easy though - the tech is definitely much harder than it should be.