Do we really need id_token in implicit flow in OIDC?

0
votes

I'm working on a SPA application, and I'm using the recommended implicit flow and I'm able to get access_token and id_token. As I need more than the profile info, I've created a separate endpoint to return the user profile information (along with all the other information that's specific to our business) and this endpoint is protected, and can be accessed only with an access_token as the bearer token. Right after getting access_token in SPA, I call this endpoint to get all the user information (which includes first name, last name etc., that gets displayed on the UI). If there is any problem with the returned id_token and access_token pair, the user profile info endpoint call would fail. So, do I really need to validate the id_token? as I'm not relying on any information within that token.

For authenticating against external login provider or authorization code flow, validating the id_token makes sense, but in my case I'm not sure about it.

According to OpenID spec:

When using the Implicit Flow, the contents of the ID Token MUST be validated in the same manner as for the Authorization Code Flow, as defined in Section 3.1.3.7, with the exception of the differences specified in this section. 1. The Client MUST validate the signature of the ID Token according to JWS [JWS] using the algorithm specified in the alg Header Parameter of the JOSE Header. 2. The value of the nonce Claim MUST be checked to verify that it is the same value as the one that was sent in the Authentication Request. The Client SHOULD check the nonce value for replay attacks. The precise method for detecting replay attacks is Client specific.

1
identityserver4openid-connectidentityserver3
Wondering why you made an extra endpoint why not just use docs.identityserver.io/en/release/endpoints/userinfo.html? – DaImTo
@DalmTo: as I mentioned our customized endpoint returns more than the regular user identity related info, and it's in a different database... so I didn't want to bring that into IdP – Gokulnath
why do you use OpenID Connect at first place ? – Kavindu Dodanduwa
@KcDoD only one of the applications that we're building is SPA, and we have a few MVC, mobile and other applications too... other OIDC flows are useful for the other apps – Gokulnath
Validating the refresh token even if you don't use it thereafter has benefits as the validation includes checking the nonce which ensures you're getting the expected response. The oidc-client-js library does this all for you though, are you using that? – mackie

1 Answers

1
votes

Why don't you utilise response_type parameter in authorisation request. By changing its value, you can alter what you receive for authorisation response.

Identity documentation mention about possible response type values. Following is an extraction from their documentation,

enter image description here

As you can see, if you do not want SPA to receive the id token, you can set the response_type value to token. If you do so you will only get an access token, which is enforced by OAuth 2.0 specification. (See the OAuth 2.0's implicit flow response_type explanation from here). Note that when you use response_type=token , you are using OAuth 2.0 (not OIDC)

I don't see any wrong in your approach as long as you utilise features enabled by respective protocols.