Restlet OAuth2.0 draft30 extension development note.

oatuh2-dev-note

OAuth 2.0 draft30 Note.

1.7. HTTP Redirections
	* We use '307 Temporary Redirect' via #redirectTemporary method generally.
	
1.8. Interoperability
	* TBD: Client implementations.
   
2. Client Registration
	* ClientStore has 2 methods to specify client type(confidential/public).
	* Each client creation methods has mandatory parameter to specify redirection URI.
	
2.2. Client Identifier
	* TODO: Should specify client identifier size.
	
2.3. Client Authentication
	* XXX: BASIC authentication?
2.3.1. Client Password
	* ClientVerifier is provided to support BASIC authentication.
	* Alternative method(Including the client credentials in the request body) is enabled via #setAcceptBodyMethod.
	* TEST IS REQUIRED.
2.3.2. Other Authentication Methods
	* Not supported.
	
2.4. Unregistered Clients
	* N/A
	
3. Protocol Endpoints
	* Auhtorization endpoint is provided via AuthorizationServerResource.
	* Token endpoint  is provided via AccessTokenServerResource.
3.1. Authorization Endpoint
	* AuthSession is used to verify the identity of the resource owner.
	* TODO: The endpoint URI MUST NOT include a fragment component.
	* Use of TLS(HTTPS) should be implemented on Restlet user application.
	* We support HTTP "GET" and "POST" method.
	* TODO: Should check parameter duplication.
3.1.1
	* TEST IS REQUIRED: response_type
	* TODO: Extension response types.
3.1.2
	* TODO: We should ensure that redirection URI NOT include a fragment component while its registration.
3.1.2.1. Endpoint Request Confidentiality
	* TODO: If TLS is not available, the authorization server SHOULD warn the resource owner about the insecure endpoint prior to redirection (e.g. display a message during the authorization request).
3.1.2.2. Registration Requirements
	* We require all clients to register their redirection endpoint. (in ClientStore)
	* We support dynamic redirection URI.
	* We do not allow the client to register multiple redirection endpoints. (in ClientStore)
3.1.2.3. Dynamic Configuration
	* TEST IS REQUIRED: redirect_uri
3.1.2.4. Invalid Endpoint
	* AuthorizationServerResource returns error page in such cases.
3.1.2.5. Endpoint Content
	* Client's responsibility.
	
3.2. Token Endpoint
	* TODO:  The endpoint URI MUST NOT include a fragment component.
	* Use of TLS(HTTPS) should be implemented on Restlet user application.
	* We only accept HTTP "POST" method.
	* TODO: Should check parameter duplication.
3.2.1. Client Authentication
	* Typically ClientVerifier is used to authenticate the client, and it's Restlet user application responsibility to do so.
	* TODO: We should support both public clients and confidential clients on ClientVerifier.
	* TODO: draft31 update for client_id.
	
3.3. Access Token Scope
	* TokenVerifier is used to protect resources, and it set Roles as scopes.
	* RoleAuthorizer will be used to verify scopes after TokenVerifier.
	* "defaultScope" parameter in context's attributes will be a pre-defined default value when the scope parameter is omitted.
	
4. Obtaining Authorization
	* authorization code, implicit, and resource owner password credentials are supported.
	* TODO: client credentials is not supported at this time.
	
4.1. Authorization Code Grant
4.1.1. Authorization Request
	* TEST IS REQUIRED
	* If the AuthSession's scope owner(e.g. resource owner) is null, AuthorizationServerResource redirects client to the login page endpoint. The query parameter "continue" will be added to the endpoint.
	* Otherwise, it will redirect to the AuthPage, with query parameter "scope" and "grantedScope" if available.
4.1.2. Authorization Response
	* TEST IS REQUIRED
	* TODO: Support the code lifetime.
	* TODO: Should clarify code value size.
4.1.2.1. Error Response
	* TEST IS REQUIRED
4.1.3. Access Token Request
	* TEST IS REQUIRED
	* Client authentication should be done before AccessTokenServerResource.
	* TODO: Ensure the authorization code was issued to the client.
	* Code validation must be done by TokenGenerator implementation.
	* TODO: Validate the "redirect_uri" paramter if present.
4.1.4. Access Token Response
	* N/A
	
4.2. Implicit Grant
4.2.1. Authorization Request
	* TEST IS REQUIRED
	* Exactly the same as the "Authorization Code Grant".
4.2.2. Access Token Response
	* TEST IS REQUIRED
4.2.2.1. Error Response
	* N/A

4.3. Resource Owner Password Credentials Grant
	* TODO: Should provide the method whether enable this grant type or not.
4.3.1. Authorization Request and Response
	* N/A
4.3.2. Access Token Request
	* TEST IS REQUIRED
	* Client authentication should be done before AccessTokenServerResource.
	* TODO: the authorization server MUST protect the endpoint against brute force attacks.
4.3.3. Access Token Response
	* N/A

4.4. Client Credentials Grant
	* Not yet implemented.

4.5. Extension Grants
	* Not yet implemented.

5. Issuing an Access Token
5.1. Successful Response
	* TODO: Set Pragma header field with a value of "no-cache".
5.2. Error Response
	* TODO: Set Pragma header field with a value of "no-cache".

6. Refreshing an Access Token
	* Client authentication should be done before AccessTokenServerResource.
	* Refresh token validation must be done by TokenGenerator implementation.
	
7. Accessing Protected Resources
	* The token validation has to be done by TokenAuthServerResource.
	* TokenVerifier is used to protect resources as described in 3.3.
7.1. Access Token Types
	* We support Bearer token only at this time.
7.2. Error Response
	* TokenVerifier should response with "error".
	
8. Extensibility
	* XXX: Should we provide the extension mechanism?
	
9. Native Applications
	* TBD
	
10. Security Considerations
	* TBD
	
11. IANA Considerations
	* N/A