OAuth2 Exts.
Title: OAUTH 2 Extensions
Session: (W2F)
Conference: IIW-11 November 2-4, Mountain View, Complete Notes Page
Convener: Justin Richer & Marius Scurtescu
Notes-taker(s): Marius
Discussion:
File:NativeClientExtension.pdf
File:UnregisteredClientExtension.pdf
Hosts (and only participants): Justin Richer & Marius Scurtescu
We talked about several proposed OAuth 2 extensions that we worked on or we thought are important:
- Instance Information
- XML Encoding
- UX
- Unregistered Clients
- Native Clients
- Token Types
Instance Information and Unregistered Clients are somewhat related and we explored if they can be combined. In the end we decided that they are orthogonal and should stay as separate extensions.
For Unregistered Clients the proposal is to specify well known values to two existing parameters and add a required and two optional parameters:
- client_id=anonymous
- client_secret=anonymous
- client_name - required
- client_description - optional
- client_icon - optional
We explored alternate ways to signal an unregistered client, specifically to omit the client_id and client_secret parameters from the request. The problem with this approach is that these two parameters are required by the core spec so generic libraries that are not aware of this extensions will have problems handling messages like these. Also, a potential benefit in providing these parameters with special values is that some code paths in the authz server implementation can stay agnostic to the client type (by hard coding a fake registration for anonymous/anonymous for example).
The only issue with special values is that a client id of "anonymous" my collide with a legitimate registered client. For Instance Information the two proposed new parameters looks fine:
- instance_name
- instance_description
For symmetry we should consider adding a instance_icon, maybe.
For Native Clients we discussed an extension that allows the client to specify that it does not have a redirect URI, and that the authz server should provide a default one in this case. The extension also specifies the that default page should add the response to the <title> tag in a specific way so it shows up in the window title. This allows clients to implement OS specific window title scraping.
- redirect_uri=oob
- <title>Success code=123&state=abc</title>
We also considered adding an optional parameter called "instructions" through which the client can provide additional instructions to the end user.
The Token Types extension introduces three new optional request parameters, all are hints from the client for the authz server. These allow the server to issue only the tokens that the client really needs: - tokens=[access|refresh] - expires_in - optional - token_usage=single
tokens tells the authz server what tokens it needs. A web based client may not need a refresh token, during refresh a client may want a new refresh token, when swapping an authorization code a client may need only a refresh token.
expires_in allows the authz server to issue access tokens that expire sooner than the default, this allows lowering the load on the server if some clients are asking for a large number of tokens in short periods of time.
token_usage allows clients to ask for access tokens that are single use. This allows reducing load, as before, or reduce the risk if tokens are sent over insecure channels (think One Time Password). We also considered this parameter to take a number as value, instead of "single", and this number to represent the number of uses allowed for the access token, in this case 1 == single.
We noted that expires_in and token_usage can be approximated by using token revocation endpoint.
XML Encoding should rely on an automatic mapping between the JSON format and the XML format. We considered generalizing this extension and also allow for form encoded responses. One possible issue with form encoded is that it allows only name/value pairs, whereas JSON and XML allow for tree structures. For now all responses are name/value pairs, and maybe it should stay like that, to be similar to requests and in browser responses.
