[Native App SSO] No prescriptive restriction on the authorization server to protect an actor-less token exchange

[Vivek Shankar]

Thank you for the OpenID Native App SSO spec. It solves a real-world problem. I have a proposed update to this spec.

REF: https://openid.net/specs/openid-connect-native-sso-1_0-ID1.html#section-4.3

The native app SSO flow’s token exchange profile expects the actor token is going to somehow be mandatory. However, OAuth 2.0 token exchange does not mandate that the actor token is required. Should this perhaps be prescriptive? For example, if the ds_hash claim is present in the subject token, the corresponding device_secret must be provided as an actor token.

Given the spec hinges on the pairing of the id_token and the device_secret for the token exchange profile, this seems important to prescribe. This is necessary, IMHO, to avoid badly written clients just using the id_token to obtain an access token, which is the ultimate goal for those client apps.

Failing to have something like this in place forces OPs to come up with their own bespoke enforcement. Not having some form of enforcement, IMO, can cause inadvertent exposure in a real implementation.

[Vivek Shankar]

I agree that RFC 8693 does not make the actor_token REQUIRED. However
section 4.1 of the implementor's draft profiles RFC 8693 and makes the
actor_token mandatory (REQUIRED) for the Native SSO spec.

I'm happy to consider additional text if you feel it is necessary and you
have some to suggest.

I am trying to figure out how the authorization server should enforce the need for the actor token. Here are a few options I can see having potential:

1. Similar to grant types, enable “Native App SSO” as a feature toggle on the client configuration. This automatically enforces the need for the device secret actor token.
2. Generic “actor token required” flag that pairs with a “supported actor token types”
3. If the incoming id_token has “ds_hash” claim, it must have a corresponding device secret actor token

Do you have any recommendations?

[gffletch]

My apologies for taking so long to get back to this.

I can see value in defining an openid-configuration flag to identify that the AS supports this specification.

The processing rules already require the AS to ensure that the binding between the id_token and the device_secret is valid. I can add some explanatory text so say that this validation is done by validating the ds_hash claim in the id_token. Since the actor_token is REQUIRED to call the token endpoint with this profile, the device_secret MUST always be presented. The AS can determine if the client is using this profile by checking the actor_token_type which MUST be urn:x-oath:params:oauth:token-type:device-secret.

Does this address your concerns? I’m working on a PR to address this an some additional feedback.

[Vivek Shankar]

The notion that the actor_token is required should perhaps be a client property? Given this is not a new grant type and is just extending the token exchange grant type by adding a new token type, the AS needs some guidance in the configuration to indicate that the actor token is required and should be this device-secret token type.

In any case, this is how I have ended up implementing it to distinguish clients using native app SSO vs clients that simply exchange an id_token for a new access token. Basically I have introduced two new properties at the client level:

1. supported_actor_token_types
2. actor_token_required

‌

With this the AS is able to enforce the use of native app SSO vs not. Another approach we considered (and rejected) was to look for the ds_hash claim in the id_token (provided as subject token) and the existence of which requires that the device secret actor token be provided. The reason for not going down this path was to cover the use case where the id_token is truly used as an identity assertion that is used to exchange access tokens.