3

I have an application that stores the id_token in the localStorage of the browser.

Since there is no CSP and Web Storage does not have the same protections such as cookies (HttpOnly, SameSite) this "feels wrong" to me.

Unfortunately I am not familiar enough with OpenID Connect to properly assess the risk. I can see that the application uses several APIs for which it requests access tokens, but I am not sure if and how id_token has anything to do with that.

Can I leverage the id_token to obtain an access token or would I need more information (like the client secret) for that?

I just found out that not only does the application store the id_token, but also an access token scoped for 'openid'. From what I understand so far, it should be possible to use this access token to request more info about the user via the /userinfo endpoint. Correct?

1
  • I think more intel is required to give a concise answer. The client is probably merely storing the ID token to persist the claims such as Email address for display reasons, but your suspicion is justified as storing the whole token including signature should be avoided. "Can I leverage the id_token to obtain an access token?" - No, that would either require a refresh token or granting consent once again. If the id token contains a nonce parameter it's also likely it has been invalidated at the point it is stored.
    – Beltway
    Nov 11, 2021 at 12:00

1 Answer 1

2

The id_token is a signed attestation about the user’s identity. Including his sub ID at a given iss (issuer) in the ID Token should be enough to identify him.

More claims about him might be included in the id_token if no access_token was issued when using the implicit flow. Otherwise other claims about the user can be obtained at the userinfo endpoint by authenticating with the access_token.

So what can an attacker do with a stolen id_token?

  1. An attacker may parse it to obtain personally identifiable information (PII). The sub itself is not such sensitive information. The impact may depend on the specific case. If the id_token contains other more sensible claims like the user’s email, address or birthdate, this information is also available to the attacker.
  2. RP-Initiated Logout allows the (RP) Relying Party to request the OpenID Provider to sign out the user. Providing the id_token in this flow is recommended.
    An attacker might construct a link and send it to the user. If the user opens the link, he will be signed out at the OpenID Provider. Bad, but not that dangerous.
  3. Some resources (APIs that accept access_tokens) and OpenID Provider do not use the aud (Audience) claim in JWT (JSON Web Token) in correct way. The aud claim determines for whom the token is intended. The id_token should contain the client_id of the RP for whom it was issued. An access_token might be a JWT and thus also contains an aud claim. In that case it must be an identifier for the resource(s) for which this token is authorized.
    If e. g. an API just checks the signature and expiration of the JWT access_token, it will also accept an id_token instead of an access_token.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .