A additional life cycle showing how the server can avoid storing state for the client in the current spec.
|
new use case jwt.xml
Description: XML document
Open registration, with no authorization required on the client registration endpoint. The registration endpoint/Authorization server maintain no state for the client. All information is storted in the client_id that is returned to the client and passed back to the Authorization server and Token Endpoint on subsiquent requests. If the client is using the implicit flow then the JWT MUST include the redirect URI and be signed by the AS for its later consumption. If the client is registering it's public key for use in the self signed assertion flow, the JWT MUST include the client's public key in the signed JWT. If the client is using a symetric client secret, the AS MUST include the secret as a claim in the JWT and encrypt or sign and encrypt the token to itself as appropriate. This method is transperent to the client and requires no aditional paramaters. The flow works as follows:
- A client needs to get OAuth 2.0 tokens from an authorization server, but the client does not have a client identifier for that authorization server.
- The client sends an HTTP POST request to the client registration endpoint at the authorization server and includes its metadata.
- The authorization server creates a JWE containing the required metadata such as redirect_uri and client secret for http basic authentication. (For clients using the assertion flow for authentication the registration endpoint can create a JWS containing the clients public key)
- The authorization server issues the JWT as the client identifier and returns it to the client along with a JWT registration access token and a reference to the client's client configuration endpoint. (The client_id cannot be changed currently so updates are not possable the registration access token would only allow for reads)
- The client stores the returned response from the authorization server. At a minimum, it should remember the values of client_id, client_secret (if present),registration_access_token, and registration_client_uri.
- The client uses the its client_id and client_secret (if provided) to request OAuth 2.0 tokens using any valid OAuth 2.0 flow for which it is authorized.
- If the client's client_secret expires or otherwise stops working, the client must re-register.
|
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
