[Native SSO] Codify login_required / consent_required errors on token exchange?

[Vladimir Dzhuvinov]

When a native app performs back-channel SSO, the OP may decide that for some particular requested scopes the user may need re-authenticate, or consent explicitly (in the browser). At present we’re not sure how to signal this. That’s because the invalid_grant error is too general. I then realised that in OIDC Core we have the error codes login_required and consent_required (and also interaction_required) and that they may help to solve this.

Here is their definition in OIDC Core:

https://openid.net/specs/openid-connect-core-1_0.html#AuthError

I’d love to hear thoughts, or suggestions if something better could be done here.

[gffletch]

Yes, I think we can do better and should update the spec with some text. At the moment I’d lean toward interaction_required over the others as it is pretty generic and leaves what interaction is required up to the OP. I’m open to other opinions

[Vladimir Dzhuvinov]

Thanks George for this idea. The interaction_required looks optimal. It covers all cases - OP requires auth for the requested scope, OP requires consent, OP requires both auth + consent. One instead of 3 *_required errors for RPs to watch for, this is simpler.

This would then leave the invalid_grant error for these cases:

• Invalid ID token
• Invalid device_secret
• Invalid device_secret - ID token subject binding (ds_hash)

(looking at our prototype code now)

What I aim to achieve is zero support calls when native SSO rolls out somewhere. It looks like getting the error codes right is crucial here. One for the case when the RP should simply go back to the authZ endpoint for re-auth / consent (interaction_required), and another the case when the client app is clearly doing something wrong, or we have malicious activity (invalid_grant).

‌

[gffletch]

So another question… if the client receives the interaction_required error and then opens a web context for the interaction, how is the current authentication state carried to the AS? I don’t think the device_secret should be passed in the URL.

We could use PAR, but that is a big normative change.

If the client just starts a new authorization flow, then should it send the device_sso scope and overwrite the device_secret with the one that comes back from this new flow?

Maybe we should discuss this on an upcoming working group call?

[gffletch]

Here is the text I’m considering so far…

In the case that the AS requires the user to interact with the AS directly, the AS MUST
return the OpenID Connect defined error of <spanx style="verb">interaction_required</spanx>.
This instructs the client to start an authorization request with the AS via the standard
web based flows.

‌

[Vladimir Dzhuvinov]

We did a little experimenting, using the new interaction_required error for the token exchange grant to signal these cases:

1. The device session established by the submitted device_secret has expired.
2. The device session is still active, but requires the user to re-authenticate (due to its max auth_age expiring)
3. The requested scope value or OpenID claim requires the user’s consent.

Provided the RP restarts the authZ flow and doesn’t forget to submit its existing device_secret together with the code at the token endpoint, what you describe as the auth state / device session state at the OP will get correctly updated in cases 2 and 3. In case 1 because the device_secret that the RP submitted has expired, the OP will return a new value.

Section 3.3 clearly says the RP should include its device_secret whenever it makes a token request with the code grant, so there doesn’t seem to be any need to require anything additional from the RP (or the OP).

device_secret

OPTIONAL. This token SHOULD be provided if the client requested the device_sso scope and the client already has a device_secret available.

This means the proposed text is going to be sufficient.

Here is a small edit to give readers an idea why the interaction_required may be useful.

In the case that the AS requires the user to interact with the AS directly, for example to
obtain the user's consent for a particular requested scope value, the AS MUST return the 
OpenID Connect defined error of <spanx style="verb">interaction_required</spanx>. This 
instructs the client to start an authorization request with the AS via the standard web 
based flows, as described in section <xref target="AuthZReq/>.

‌