https://www.ory.sh/ logo
Join Slack
Powered by
This message was deleted.
# general
m
This message was deleted.
l
Access tokens have a perfectly legitimate reason to be used in OIDC relying parties. They provide the following: 1. Permission information represented by scopes and the 
authorization_details
(new rich authorization request) that is used to determine what should be allowed on the application. 2. Contains user consent information that drives privacy decisions on the client app. 3. Authorize resource API calls: With regards to what you mentioned about SPAs or, in general, API calls made from an untrusted user agent, this is a concern because the token can basically be copied and used elsewhere. This is mitigated today with shorter lifespans, but the real mitigation is in the form of sender-constrained access tokens. For pure SPAs with no backend, they would use distributed proof of possession (DPoP) - currently in draft 09 and I still have some concerns with that spec particularly from a MITM perspective. If the app has a backend, certificate bound access tokens are probably the best choice.
In summary, anything that an OAuth client would use an access token for, IMO, still applies to OIDC clients. The OIDC clients merely add a dimension to obtain user profile information without making a non-standard profile API call authorized by the access token.
a
One possible counter argument to that is that OIDC doesn't extend OAuth2, but uses it for a different purpose and as such can impose restrictions on things like the access token. A couple points to prove that: • You'll never use client credentials grant with OIDC, because there is no identity there. • When you define scopes for the OIDC flow, you can't define scopes separately for the access token and separately for the id token. They have to be the same which isn't necessarily a good thing. For example, if you want to use the profile scope to grant an application access to edit your profile...well, you can't really control which client can do that and which can't. Edge case, I know. Another concern is that relying parties don't always implement the token introspection endpoint which makes the access token useless in an application context. If the ability to use the access token for other purposes changes from implementation to implementation....well, that's bad. For these reasons, I'm generally closer to saying it's not a good idea to use the access token for anything but the userinfo endpoint and that initiating a new session based on the ID token (exchanging it for a cookie or an application issued token) is a better idea. Any thoughts?
l
scope
is not included with your id_token. It's in your introspection payload.
Yes, there are certain grant flows that are pure OAuth and there are those that are extensions like the authorization code flow which includes user authentication.
The addition of the id_token does not negate the needs of making API calls authorized by a bearer token. The format of the access token can be opaque or a JWT
The 
scope
is a representation of permissions granted to an app and, in OIDC, the set of standard scope values (such as profile) dictate the user profile attributes that should be made available to the RP. Should the request have separated scope (for the purposes of permissions) from the claim aggregates like profile? Sure. But the decision to not do so likely stemmed from the fact that an app is effectively requesting that a user grant access to certain parts of their user profile.
Here's a real use case where both are needed - payment transaction that needs to be authorized with a bank. In this flow, the RP generates requests for 
code id_token
. It requests for 
id_token
because it needs user profile information to be presented on the page. It needs an access token because that token is then used to authorize calls to the /payments API hosted by the bank. The id_token cannot be used for this purpose because it does not contain the consent information (represented by scope or authorization_details). It would also potentially not contain the 
amr
that indicates strong authentication has been completed.
a
I'm not trying to debate you, but I'm not really convinced so far. In your last example you are essentially saying that OIDC is supposed to provide both authentication and authorization. That just feels weird to me.
l
No, in the last use case, it is purely authorization. Authentication is handled by the OIDC OP as it would in any auth code flow. Usually delegated to an authentication service like Kratos.
a
Thanks for the conversation @late-tiger-78467!
👍 1
7 Views
Open in Slack
PreviousNext
Powered by