Differences from OAuth
Token authorization on the web is generally associated with OAuth. A typical OAuth 2 flow looks something like this:
Application requests access from user to access a resource server
Browser redirects to an authorization server
User authenticates with the authorization server
User selects the rights they would like to allow
Authorization server provides a temporary grant
A grant record is created on the authorization server
Browser redirects back to the application
User provides the grant to the application
Application makes a request to the authorization server with the grant
The grant is exchanged for a time-limited access token with the rights the user specified
The grant is invalidated in the authorization server's records
The application uses the token to make the request to the resource server
Resource service validates that the token is valid with the authorization server
Resource server performs action
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:
Application requests access from user
User is redirected to a well-known (potentially self-owned) authorization webpage
Ideally a cached page, well known, and outside the influence of the application
User reviews and approves the appropriate permissions
User signs a JSON object that includes the delegated rights and the recipient
Browser redirects back to the application
User provides the self-signed token to the application
Application uses the token to make authenticated requests to the resource server
Resource server authenticates the application, user, and verifies authorization level
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.
