CIBA: Notifying the Client when a user fails to authenticate

[Dave Tonge]

We discussed this issue on the call today. The thrust of the discussion was the following states:

1. User authenticates but doesn't not authorize
2. User fails to authenticate
3. User never attempts to authenticate in a given (OP determined) time
4. The auth request itself expires

There was a wide ranging discussion, but I believe the general agreement for the above states was:

1. There must be a access_denied error
2. There could be an access_denied error or an auth_timeout error
3. There could be an access_denied error or an auth_timeout error
4. There should be a auth_req_expired error (but OPs shouldn't be required to notify Clients of this error)

Note there currently isn't a auth_timeout error - we can decide on the best name. Also there is currently an expired_token error, but is used for multiple errors, this is why I think that perhaps something more explicit like auth_req_expired may be better.

[Gonzalo Fernández]

From my point of view, 2 and 3 must be access_denied. The rational of such choice is to avoid disclose information about authentication for potential attacks. Particularly I don't see how the "auth_timeout" response can fit in number 2.

Regarding number 4, I am confusing, what does "the auth request itself expires"? The auth_req_expired means that the auth_req_id is no longer valid and for me in that case the error for the client could be "access_denied" as well. Does would work for you?

[Dave Tonge]

So the reason for allowing the implementation of an auth_timeout is allowing the RP to know whether the user explicitly refused access or whether they just didn't have their phone with them.

I agree that there are disclosure issues, but when dealing with async processes it seems fair to specify a way to differentiate between these two scenarios. In redirect based OAuth there is an interactive session and its unlikely that there will be a timeout issue.

What attacks are you thinking of that could make use of an auth_timeout error?

[Gonzalo Fernández]

Maybe is not considered a security attack in terms of eavesdropping, tampering, etc... and I don't know if is important enough, but a "malicious" Service Provider that would want to contact with other users (that are not Service Provider consumers/clients) would obtain an information about the subscription of this user in the OpenID Provider Autentication Service (e.g: Mobile Connect). And could use it to contact him or spam them in order to be suscribed in the Service Provider once it knows that it could use CIBA to authenticate him.

[Dave Tonge]

Agreed to do a pull request to add in the different error type - but make it optional and add in privacy considerations

[Dave Tonge]

To implement this we would need to register a new error code. I suggest that we move this to a later implementers draft if we still want to do it.

Currently I've been able to use the error codes registered by OAuth device flow.

[Joseph Heenan]

I'm struggling to see the difference between '3' and '4'. What is the use case where the OP would return an auth_request with a longer lifetime than the time the OP allows for the user to authenticate?

Is '1 User authenticates but doesn't not authorize' the same as "user authenticated and explicitly rejects authorisation" or is it trying to get at a more subtle case where the user authenticates but then doesn't respond to the authorization step?

Assuming "2" is "user reaches some OP determined limit on number of times they can fail at authenticating (ie. putting in wrong password too many times)"

[Dave Tonge]

So I've proposed a change to the definition of expired_token here: https://bitbucket.org/openid/mobile/pull-requests/57/expand-the-definition-of-expired_token/diff

This will allow OPs use expired_token for states 2, 3 and 4 above (they of course could also use access_denied for states 2 and 3).

[Dave Tonge]

So this was discussed on the last call. Let me try and update the issue based on some changes we have in the spec since this issue was first raised:

We have the following states:

1. User authenticates but does not authorize
2. User fails to authenticate
3. User never attempts to authenticate in a given (OP determined) time
4. The auth request itself expires
5. There is an error somewhere that prevents the OP from even reaching out to the user

The use-case we want to support is:

As an RP who has a user that is genuinely trying to authenticate with the OP and authorise my request I want to present helpful messages to the user.

We have the following error type from the token endpoint

• authorization_pending
• expired_token
• access_denied

And these errors for push mode:

• expired_token
• access_denied
• transaction_failed

Given that an RP can now send a requested_expiry param, my understanding of the behaviour of the RP and OP for the above states are:

User authenticates but does not authorize A access_denied error should be sent (some for all 3 modes). RP tells the user that the authZ/authN process failed and asks them to try again

User fails to authenticate A access_denied error should be sent (some for all 3 modes). Although we should decide if we are happy with the current definition (take from device flow) or whether we would rather use the RFC6749 definition which is wider. RP tells the user that the authZ/authN process failed and asks them to try again

User never attempts to authenticate in a given (OP determined) time Given that the RP can request a short requested_expiry param, I would hope that the RP and OP share the same view on what the appropriate time is. The RP can show the user a "waiting for auth" message. For poll mode the OP will be sending the RP authorization_pending errors. For push mode, the OP won't send anything until the request expires.

The auth request itself expires The OP sends an expired_token error to the RP. The RP tells the user that the session has expired and asks if they want to try again

There is an error somewhere that prevents the OP from even reaching out to the user In push mode the OP can send a transaction_failed error. In poll mode I'm not clear what the OP would send?

From my perspective I think we should be clearer on what the OP should return in the above case for poll mode. I think we also need to agree on which definition to use for access denied. Apart from that I no longer see a requirement for any other error. I think the addition of requested_expiry to the spec better supports the use case of an RP who has an interactive session with a user and needs the request authorized in a short period of time.

[Dave Tonge]

From the last call:

Discussions about “access denied” and “failed authentication” error codes. Joseph to write additional text to the issue, clear the understanding of error messages

[Dave Tonge]

Discussed on the call and agreed to close this issue for now while we wait from feedback from implementers.