SL1 - are access tokens part of SL1?

[dickhardt]

Why does SL1 need to specify an access token? While they are used for userinfo calls -- it is generally a one time use. I think we need to clarify what else besides userinfo we would need.

Building on that, it would seem access tokens for other resources that may be at the identity service to be out of scope.

How an RP manages its own 1P access / refresh tokens is also important, but I think independent of session lifecycle with the exception that the RP should be able kill refresh tokens.

[dickhardt]

having thought about this overnight, I think that access tokens should NOT be part SL1

[brockallen]

Should not at all or should not be required? IOW, you're suggesting that only OIDC implicit grant type be used?

[dickhardt]

I think the implicit grant should be forbidden, and only the authorization_code grant be supported.

As OIDC is built on OAuth 2.0, and OAuth 2.0 requires an access_token in a successful response from the token endpoint, many have interpreted that an access_token MUST be returned as well as an id_token

To simplify compliance, I propose that IPSIE specifies that the userinfo endpoint is not supported and that an access_token is not included in the response -- but that would be a breaking change for many OPs. I'd settle for IPSIE being silent on the access_token, and require an id_token to be be returned from the token endpoint, and the RP MUST only use the id_token to determine the user identity. IE, it cannot use an access token and get the sub from the user_info endpoint

The user_info endpoint is used at times to return all the groups a user belongs to. This falls into the identity lifecycle dimension of IPSIE which is a different conversation.

[brockallen]

I think the implicit grant should be forbidden, and only the authorization_code grant be supported.

I meant with form post, but yea, I guess code flow works too (as the id_token comes on the backchannel).

I'd settle for IPSIE being silent on the access_token, and require an id_token to be be returned from the token endpoint, and the RP MUST only use the id_token to determine the user identity.

I don't see anything that we don't expect claims to be delivered via the id_token. So then not allowing the userinfo endpoint makes state management in the RP with the id_token a potential problem (for use at logout time) if there are lots of claims. I've seen large cloud enterprise token servers have 200+ roles/groups delivered to the RP (for better or for worse).

[mcguinness]

+1 to authorization_code grant + PKCE using OAuth 2.1 and Security BCP as foundation as the only flow defined in SL1 for IPSIE.

For interoperability with the existing ecosystem of RPs and toolkits, I was thinking IPSIE SL1 does not support the offline_access scope (no Refresh Tokens) and only supports profile, email, address, phone, with the required openid.

IPSIE would also specify that the UserInfo access_token lifetime can be bound to the same lifetime as the id_token. This would enable folks to fetch claims on backchannel if needed (e.g large groups/tokens) but only during SSO flow and not use the access_token for sync outside of SSO. We already need to ensure that communication between the RP and OP over HTTPS is secure so the risk of exfiltration of the access_token that is time limited to SSO (e.g 5 mins) is reduced as the RP wouldn't see value in persisting this token (just cache with TTL)

[brockallen]

For interoperability with the existing ecosystem of RPs and toolkits, I was thinking IPSIE SL1 does not support the offline_access scope (no Refresh Tokens) and only supports profile, email, address, phone, with the required openid.

Only allow, or requires at a minimum? I see custom scopes (often in favor other than profile, email, etc) all the time in OIDC to model a variety of enterprise types of identity data.

[mcguinness]

This is the challenge, the moment you start requesting vendor-specific scopes during SSO to other protected resources at the IdP (not UserInfo) then this all starts to look like FAPI2. This is the debate that #59 & #61 is having.

[dickhardt]

I'm aligned on Karl's suggestion.

@mcguinness 5 minutes seems like a long time for an access_token or id_token that would be consumed immediately. How about 60 seconds similar to the authorization code?

I also think other "scopes" should be allowed, but only identity related scopes that would translate into claims, not scopes that provide access to resources with the access_token.

[brockallen]

This is the challenge, the moment you start requesting vendor-specific scopes during SSO to other protected resources at the IdP (not UserInfo) then this all starts to look like FAPI2. This is the debate that #59 & #61 is having.

Well, I was more asking around the use of custom scopes and/or the claims param to request additional user claims (beyond those of profile, et al) in the id_token (or from userinfo). So not other resource server endpoints, as it were.

I also think other "scopes" should be allowed, but only identity related scopes that would translate into claims, not scopes that provide access to resources with the access_token.

Yes, this is what I was trying to get at. So +1.

[mcguinness]

I'm good with @dickhardt take that if they are identity related scopes that release claims in id_token or userinfo then its fine. I was just trying to see if we can create a boundary around userinfo as some IdPs are also app platforms and have large resource graphs that can be requested along with SSO.