There are three well-defined methods for obtaining a token: 1. Web Delegation (2 steps) - user is redirected to the server, authorizes, redirected back to client with token. 2. Web Delegation (3 steps) - client obtains temporary credentials, user authorizes at the server, client exchanges temporary credentials for token. 3. Direct Request - client uses the user's username and password to request for a token. OAuth Core 1.0 supports the #2 option only. There is clear demand for the other two methods. Many large providers I talked to would like to have #1 to get rid of the temporary credentials (request token). The vast majority of the temporary credentials are never used and waste resources. The 3-steps flow was created to address clients which are unable to receive redirections and therefore have no way to get the token back from the server. Many developers have asked for #3 for cases where it is perfectly acceptable for an application to have access to the user's credentials, but still provide a single OAuth-based API. This has been also raised in cases where opening a browser is poor or unacceptable user experience. When making a token request, the client may be required to authenticate itself (using its client credentials). The authentication method is either a shared secret or PK-based. When sending a token, the server should use a secure channel to ensure the token credentials remain confidential. When using a shared-secret over a secure channel, there is no reason to sign the request and simply including the secret is enough. If a PK is used, the request has to be signed in some way even over a secure channel (because there is nothing else to send with the request). Questions: - Are there use cases where the 3-step flow (#2) is needed? - Should we require use of HTTPS for token requests? - If it is ok for tokens to be sent unsecure, is it also ok to send client secrets unsecure? - How should a PK option work? What should be signed? How should it work over a secure channel? EHL
Note Well: Messages sent to this mailing list are the opinions of the senders and do not imply endorsement by the IETF.