Search code examples
securityspring-securityoauth-2.0openid-connectcloudfoundry-uaa

Is it insecure to pass id_token to browser code?

I've been digging deep into OAuth2 / OpenID Connect(OIDC) and in many ways I feel smarter, but in many ways, I'm worried that a simple mistake will leave me vulnerable. I'm building super standard business apps. So time to ask for directions:

  • Platform: Pivotal Cloud Foundry / UAA
  • Backend: Spring Boot 1.5.x (but looking at 2.0 now)
  • Frontend: React SPA
  • OAuth2: Auth Code Grant with openid scope

I'm getting the id_token, access_token, and refresh_token

I have a million questions, but lets start with the basics:

  1. Is it ok to take the id_token and just send it to the react code in the browser and have it stored in Session Storage? Otherwise how exactly is the UI suppose to know information about the person logged in?

  2. If I have the id_token, do I still care about the /userinfo endpoint? My guess is no.

  3. Every time the UI makes a call to the api it passes the auth code? Does the spring code in turn make a call to the /oauth/token every time? Should (or Does) the Spring Code cache the relationship between the auth code and returned tokens?

Solution

  • You ask just for the openid scope, so why do you need the access and the refresh token? And since you want the ID token to be used by the React application, I would suggest you to use the Implicit flow - to get the ID token directly to your frontend.

    1. You can keep the token in the SessionStorage.
    2. The ID token probably contains all the info you need, so if the /userinfo endpoint doesn't provide anything else you want, you can ignore it.
    3. Auth code can be used just once - for security reasons. So there is no point in keeping it after getting tokens. If you want to keep the backend API stateless (no session), you can use an access token. Then it's good to have a possibility to configure the backend-specific scopes at the auth server or use just the /userinfo endpoint to get info about the user. Or you can use an ID token if you want to treat the frontend and the backend as one OAuth2 client (the same ID token audience) and the user identity is all you need at the backend.