Should I send the id token from my SPA to my rest backend?

Question

I have a SPA app which is backed by a rest api server.

I use Auth0 for authentication and authorization using the implicit grant flow.
All the examples I read explain that i should send the access token which I receive to the api for authorization purpose. For example :
https://auth0.com/blog/why-should-use-accesstokens-to-secure-an-api

On the other hand, I read that access token cannot be used as a proof for authentication:
http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html https://oauth.net/articles/authentication/

That means, I cannot trust the sub claim on my access token to be sure that this is indeed the user and not another client that send its access token. Meaning, if i would use facebook as the IDP, another web app could send an access token issued to its use by the user to my server and because access tokens don't have an aud claim, my server would think that the user is authenticated in my web app. Moreover , I see that google sign in indeed guide the spa to send an id token to the server: https://developers.google.com/identity/sign-in/web/backend-auth

So : Should I send both the id token(for authetication) and the access token(for authorization) to my server ?

Answer 1

I went through Authenticate with a backend server as you have pointed out. As it suggest, one can use id token to authenticate against backend server. Which not only recomend by Google but some other entities as well. But id token is intended for relying party (client) to validate and authenticate the end user. Access token is the token that should be used to access resources.

One alternative you could consider is the use of user info endpoint defined by OpenID Connect specification.

User info endpoint

The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a request to the UserInfo Endpoint using an Access Token obtained through OpenID Connect Authentication. These Claims are normally represented by a JSON object that contains a collection of name and value pairs for the Claims.

Google do provide user info endpoint. Their documentation's Obtaining user profile information sectioon explains about the endpoint, how to call it and response details.

To obtain additional profile information about the user, you can use the access token (which your application receives during the authentication flow) and the OpenID Connect standard:

And a succesfull details will reveal end user infromation which has a format explained in People: getOpenIdConnect format.

This way you avoid exposing id token to other parties. And your backend can use the access token to access these information to detect end user and authenitcate based on that.

Regardless of these alternative approaches, id token is meant to be used for authentication. So passing it to server and use claims to identify end user and authenticate on token validity is fine as long as you protect id token.