austinsmorris/keymaster

An opinionated OAuth 2.0 server for Elixir projects.

keymaster's Issues

4.2.2 - Access Token Response (Implicit Grant)

When permission is granted the server redirects to the client redirect uri with the following uri fragment (#) requirements:

• fragment is application/x-www-form-urlencoded
• access_token - required parameter, set to the access token issued by the authorization server
• token_type - required parameter, initially will be set to "bearer" for the first implementation
• expires_in - recommended parameter - set to the lifetime in seconds of the access token. This will be used. Value should be configurable by the authorization server
• scope - optional parameter - we will always return it.
• state - required if provided in the request. I want to enforce its inclusion in the authorization request.
• do not issue a refresh token
• document the size of values returned

Note that not all user agents support a uri fragment in the Location header of a redirect response. I don't care about these user agents.

3.1.2.1 - Endpoint Request Confidentiality

Redirection endpoint is optionally https. However, I want to enforce this. No registering clients without an https endpoint.

Client Registration

Client developer shall provide:

• client type (confidential or public)
• client redirection uris
• other info (name, website, description, logo, accept terms, etc.)

Authorization server provides:

• client identifier (unique string)
• client credentials (for confidential clients - requirements vary)

4.2.1 - Authorization Request (Implicit Grant)

Access the authorization endpoint with the following query component requirements:

• query component is application/x-www-form-urlencoded
• reponse_type - required parameter, set to token
• client_id - required paramenter, set to the client id
• redirect_uri - parameter. Required if client has multiple redirect uris registered. Optional if client has one redirect uri registered. Must match a registered redirect uri if provided.
• scope - optional parameter, see #10
• state - recommended paramater - I want to make this required.
• authorization request is a GET request

remember the status of approved clients

when a user grants permissions to a client, we need a way to remember that so we don't have to ask for authorization at every login...

Is there a way to ensure SSL is being used?

4.2 - Implicit Grant

• public clients are directly issues an access token
• refresh tokens are not supported
• no client authentication - requires pre-registered redirect uri

flow:

• client directs resource owner's user agent to authorization endpoint with client id, requested scope, local state, and redirect uri
• auth server authenticates resource owner
• redirect to client redirect uri with the access token in the uri fragment
• client extracts, retains, and uses access_token

4.2.2.1 - Error Response (Implicit Grant)

failures of the authorization request resulting in notifying the resource owner (do not redirect:

• missing client id
• invalid client id (type or does not exist)
• missing redirect uri
• invalid redirect uri (typing)
• mismatching redirect uri (for the valid client)

failures resulting in redirection to the valid client redirect uri with an error response:

• missing required parameter (invalid_request)
• includes an invalid parameter (invalid_request)
• includes a parameter more than once (invalid_request)
• malformed request (invalid_request)
• client not authorized to request access token using this method (implicit grant - unauthorized_client)
• auth server does not support this method (implicit grant - unsupported_response_type)
• scope is invalid (invalid_scope)
• scope is unknown (invalid_scope)
• scope is malformed (invalid_scope)
• resource owner denies request (access_denied)
• auth server throws 500 error (server_error)
• auth server throws 503 error ('temporarily_unavailable`)

error response:

• 302 redirect to valid redirect uri

error response uri fragment parameters:

• application/x-www-form-urlencoded
• error - required to be set to one of the above
• error_description - optional - human readable description for client developer
• error_uri - optional - uri identifying human readable we page with error information for the client developer
• state - the returned state parameter from the request

3.1.2.4 - Invalid Endpoint

If the authorization request fails redirect uri validation, don't redirect. Just show the user the problem.

3.3 - Access Token Scope

• space delimited case-sensitive strings
• strings are defined by authorization server
• order does not matter
• may fully or partially ignore scope request. I don't like this, be strict
• return pre-defined client scope if scope is not in authorization request
• document available scopes, scope requirements, and default values

Need trusted clients for implicit grant type

There should be a way to mark a client as trusted (for example, it's my client). That way, login will grant requested scope.

"I don't have to grant Facebook permission to access Facebook"

3.1.2 - Redirection Endpoint

• if redirection endpoint has query parameters, those must be retained
• redirection endpoint must not include an fragment (no # in registered uri)

3.1.2.3 - Dynamic configuration

If a client has multiple redirect uris, then a redirect uri is required for an authorization request and must match a registered uri.

If a client has a single redirect uri, and the authorization request does not include the redirect uri, use the registered redirect uri.

If a client has a single redirect uri, and the authorization request includes a redirect uri, the provided redirect uri must match the registered redirect uri.

3.1.2.2 - Registration Requirements

A redirect uri is required for most cases, but only recommended for the rest. I want to enforce this for all clients. All clients much register a redirect uri. Clients may have multiple redirect uris.