5

Let's take an example where we have an SPA accessing an API using the OIDC implicit flow.

Since OAuth scopes are coarse-grained, it is often necessary to perform additional authorization on the resource servers. This can be the case for example when accessing dynamic resources (e.g filesystem) via an endpoint - where access is restricted by permissions tied to the userId, but it is not practical to use OAuth scopes only because of the dynamic nature of the resources.

In these cases the endpoint itself can be protected by an OAuth scope, while access to the resources that the endpoint operates on (e.g files) will be granted based on the userId. Hence the user's identity must be securely sent in the API request.

An obivious choice can be to send the ID token that was obtained when authenticating, together with the access token that was obtained at the same time.

There is a standard way for sending the access token in a HTTP request (the Authorization header), but is there one for the ID token? Or should I just make up a header name like 'X-Identity'?

sfThomas
  • 1,895
  • 2
  • 18
  • 26
  • If the API receives the ID Token, will it then also still need the Access Token? If not, then you might just [replace it](http://stackoverflow.com/questions/33265812/best-http-authorization-header-type-for-jwt) in your `Authorization: Bearer` (or `Authorization: JWT`) header. – Pieter Ennes Aug 08 '16 at 12:09
  • Yes, the API needs to know if the user has access to the operation that the endpoint represents (hence the access token), and to the resource that the operation is performed on (hence the id_token). – sfThomas Aug 08 '16 at 12:13

2 Answers2

3

To answer the question: there is no standard for passing the ID token in an HTTP request.

But arguably there doesn't need to be one: in this case you may not need OpenID Connect since scopes are not the only information that can be associated with an OAuth 2.0 access token as you seem to suggest.

You can "associate" the userId with the access token so that the Resource Server can grant the Client access to the protected resource based on the identity of the user who granted the access token to the Client.

The "association" is implementation dependent: the access token can be a JWT that contains the userId claim or the access token can be an opaque value that the Resource Server can introspect/validate at the Authorization Server to obtain the information associated with it.

Hans Z.
  • 50,496
  • 12
  • 102
  • 115
  • Right; I read further, trying to get my head around OAuth2 and OIDC, and it seems 'less standardized' (or more flexible) than what I was thinking. I thought OIDC gives you the possibility to replace your ID provider with minmal effort, but it looks like OIDC/OAuth2 just give you a platform to implement your own logic, so switching providers is not that easy after all. – sfThomas Aug 12 '16 at 10:11
-10

Instead of passing it in the header, you can pass it as a query parameter:

curl "https://resourcePath?auth=<ID_TOKEN>

Here's the reference: https://firebase.google.com/docs/database/rest/auth#authenticate_with_an_access_token

Antuan
  • 501
  • 2
  • 6
  • 18
  • 1
    -1 Nooo. Sending tokens as parameters is evil: https://stackoverflow.com/questions/643355/https-url-with-token-parameter-how-secure-is-it – Heinzlmaen Oct 23 '20 at 06:55
  • 1
    Evil, because they can be leaked into goodness knows how many log files as requests pass through systems. – Robert Conn Jul 28 '21 at 21:45
  • https://firebase.google.com/docs/database/rest/auth#authenticate_with_an_access_token – Antuan Jul 29 '21 at 16:27
  • @Antuan I can imagine there's low-risk situations, or testing situations where this might be handy, but it's not a good general advice (even if firebase allows it) – Evert Jul 29 '21 at 17:39