~eduvpn/server#87: 
dynamic OAuth client registration

In order to avoid the approval dialog, we could implement something like this:

https://gist.github.com/fkooman/82b39514eefe84449d208b5b296bf307

Status
REPORTED
Submitter
~fkooman
Assigned to
No-one
Submitted
1 year, 11 months ago
Updated
1 year, 1 month ago
Labels
v4.x

~fkooman 1 year, 1 month ago*

Gist is gone, so:

#Dynamic Client Registration

Our applications use OAuth public client registrations without secrets. This is because it makes no sense to embed a secret in the client the user then downloads. Those secrets are easy to extract. In order to support "public clients" the user has to approve every authorization request, which is a problem if there are a lot of those, e.g. every day.

Some platforms offer Claimed "https" Scheme URI Redirection, most notably iOS and Android. This makes it possible to remove the approval as we can be sure the client is the official client. On other platforms, e.g. Windows and macOS this is only possible when distributing the applications through the "store", which is not possible at the moment.

To tackle this problem we allow for OAuth clients to request a client_id and client_secret using an obtained OAuth token using the public client registration with the additional register scope.

The client MUST only obtain credentials once per application life cycle, i.e. request registration on initial use, and retain the client_id and client_secret for later use until the application is removed from the user's device.

With the initially obtained OAuth token the client calls the /register endpoint with a POST request, without body. The client_id and client_secret returned can be used from then on without ever triggering the OAuth authorization dialog again.

If the obtained credentials stop working, the client MUST fall back to using the public client information and restart the authorization flow.

XXX: how to detect the registered client info doesn't work any longer? This only becomes clear when triggering the authorization again? Hmmm...

  1. when the access_token was rejected (app revoked, server reset) the client doesn't know which credentials to use, probably fallback to 'public'?
  2. when the refresh_token was rejected depending on the error the client knows what the problem is and can decide to fallback to 'public client'.

So maybe it is not that difficult? Although can be tricky to get exactly right...

Register here or Log in to comment, or comment via email.