Token authorization on the web is generally associated with OAuth. A typical OAuth 2 flow looks something like this:
1.
Application requests access from user to access a resource server
2.
Browser redirects to an authorization server
3.
User authenticates with the authorization server
4.
User selects the rights they would like to allow
5.
Authorization server provides a temporary grant
1.
A grant record is created on the authorization server
6.
Browser redirects back to the application
7.
User provides the grant to the application
8.
Application makes a request to the authorization server with the grant
9.
The grant is exchanged for a time-limited access token with the rights the user specified
1.
The grant is invalidated in the authorization server's records
10.
The application uses the token to make the request to the resource server
11.
Resource service validates that the token is valid with the authorization server
12.
Resource server performs action
UCAN
In a self-signed system such as a UCAN. This closely related to a self-signed OAuth/OIDC token. Since the token is stateless, the flow is be shortened as follows:
1.
Application requests access from user
2.
User is redirected to a well-known (potentially self-owned) authorization webpage
1.
Ideally a cached page, well known, and outside the influence of the application
3.
User reviews and approves the appropriate permissions
4.
User signs a JSON object that includes the delegated rights and the recipient
5.
Browser redirects back to the application
6.
User provides the self-signed token to the application
7.
Application uses the token to make authenticated requests to the resource server
8.
Resource server authenticates the application, user, and verifies authorization level
9.
Resource server performs the action
This has several advantages, including fewer round trips, increased feasibility of short-lived or single-use tokens, and even further delegation as described above.