Hey regular readers – ignore this post, it’s a sample from the rfckit repo.

Clicking things will either load docs at the bottom, or will take you to the RFC at ietf.org.

oauth 2.0 authorization code grant ?

➡️ /client-auth
⬅️
/client-auth redirect authorization payload 📛 client-identifier 🔬 requested-scope 🔄 redirection-uri 📎 local-state
➡️ /authorization spec payload 📛 client-identifier 🔬 requested-scope 🔄 redirection-uri 📎 local-state
✅ user-agent is authenticated
✅ resource-owner grants client's access request
⬅️
/authorization spec redirect redirection-uri payload 🔑 authorization-code 📎 local-state
➡️ /redirection payload 🔑 authorization-code 📎 local-state
➡️ /token spec 🔒 client-creds payload 🔑 authorization-code 🔄 redirection-uri
✅ client is authenticated
✅ authorization-code is valid
✅ redirection-uri matches
⬅️
/token spec redirect todo
⬅️
/redirection

Docs

Role: resource-owner

Aliases: browser, user-agent, resource-owner

source Section 1.1

An entity capable of granting access to a protected resource. When the resource owner is a person, it is referred to as an end-user.

Role: client

source

An application making protected resource requests on behalf of the resource owner and with its authorization. The term "client" does not imply any particular implementation characteristics (e.g., whether the application executes on a server, a desktop, or other devices).

Role: authorization-server

source

The server issuing access tokens to the client after successfully authenticating the resource owner and obtaining authorization.

Payload: client-identifier

source

The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client.

Payload: requested-scope

source

The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. ... The authorization server MAY fully or partially ignore the scope requested by the client.

Payload: redirection-uri

source

After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request.

Payload: local-state

source

An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

Payload: client-identifier

source

The authorization server issues the registered client a client identifier -- a unique string representing the registration information provided by the client.

Payload: requested-scope

source

The authorization and token endpoints allow the client to specify the scope of the access request using the "scope" request parameter. In turn, the authorization server uses the "scope" response parameter to inform the client of the scope of the access token issued. ... The authorization server MAY fully or partially ignore the scope requested by the client.

Payload: redirection-uri

source

After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request.

Payload: local-state

source

An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

Payload: authorization-code

source

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

Payload: local-state

source

An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

Payload: authorization-code

source

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

Payload: local-state

source

An opaque value used by the client to maintain state between the request and callback. The authorization server includes this value when redirecting the user-agent back to the client.

Payload: authorization-code

source

The authorization code is obtained by using an authorization server as an intermediary between the client and resource owner. Instead of requesting authorization directly from the resource owner, the client directs the resource owner to an authorization server (via its user-agent as defined in [RFC2616]), which in turn directs the resource owner back to the client with the authorization code.

Payload: redirection-uri

source

After completing its interaction with the resource owner, the authorization server directs the resource owner's user-agent back to the client. The authorization server redirects the user-agent to the client's redirection endpoint previously established with the authorization server during the client registration process or when making the authorization request.

generated by rfckit