Edit this page

Authorization Server

In order for an OpenID Connect Relying Party (RP) to utilize OpenID Connect services for an End-User, the RP needs to know where the OpenID Provider is. RPs can use OpenID Connect Discovery.

Specifically, the extension provides an alternative method for OpenID Connect Issuer Discovery, Section 2. With Unstoppable Login, clients will resolve WebFinger information using records stored on a domain name instead of resolving WebFinger information from a server. Essentially, this process allows End-Users to specify their OpenID Provider using their domains.

Unstoppable WebFinger & Issuer Discovery

Unstoppable Webfinger uses a variety of records stored on domains to resolve a WebFinger Issuer discovery request. For Unstoppable Login, webfinger information can be stored on the domain in the following ways: by request, reference, or value.

WebFinger requires the following information to make a discovery request:

  • resource: Identifier for the target End-User that is the subject of the discovery request
  • host: Server where a WebFinger service is hosted
  • rel: URI that identifies the type of service whose location is being requested

Traditional Issuer discovery requires only the requestor resource and host to form the request, the rel must be http://openid.net/specs/connect/1.0/issuer to make an issuer request.

Example: WebFinger Web3 Domain Records

Copy
Copied
{
	“webfinger”: {
	“alice”: { “https://example.com/webfinger/rel”: “{\“uri\”:\“ipfs://Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiu\”}”

“bob”: {“https://example.com/webfinger/rel”: “{\“host\”:\“example.com\”}”},
“charlie”: {“https://example.com/webfinger/rel”: “{\“value\”:\“{...Webfinger JRD Doc...}\”}”}
}

Example: WebFinger DNS Records

Name Type Value
webfinger TXT BASE64 encoded Document from above example

By Request

This is a method used to construct a WebFinger request. The below fields are used to construct a WebFinger request, that a Client can then resolve.

Field Description
user The OPTIONAL user of the account. If one was resolving this information on domain.tld, the webfinger resource constructed would be acct:user@domain.tld. If no user is present in the record, the account would be domain itself, i.e. acct:@domain.tld.
host Server where a WebFinger service is hosted.
rel The OPTIONAL URI that identifies the type of service whose location is being requested, defaults to http://openid.net/specs/connect/1.0/issuer, used for Unstoppable Issuer Discovery.

By Reference

Field Description
user The OPTIONAL user of the account. This is interpreted in the same way as it is in the “By Request” flow.
uri A URI specifying the location of a WebFinger JRD Document. This can be a https scheme URL, or a DID, or even a decentralized storage URL.
rel The OPTIONAL URI that identifies the type of service whose location is being requested. This is interpreted in the same way as it is in the “By Request” flow.

By Value

Field Description
user The OPTIONAL user of the account. This is interpreted in the same way as it is in the “By Request” flow.
value The WebFinger JRD Document in plaintext.
rel The OPTIONAL URI that identifies the type of service whose location is being requested. This is interpreted in the same way as it is in the “By Request” flow.

Unstoppable Authentication

Unstoppable Authentication is a group of methods for authenticating End-Users of blockchain based domain names. OpenID Connect has no standards around authentication, other than metadata encoded inside jwts, e.g. amr, Authentication Method Reference Values.

Unstoppable Authentication uses two types of authentication that authorization servers will need to support Logins with Unstoppable: owner-based authentication and record-based authentication.

Owner-based authentication

This is the default authentication method used for Unstoppable Authentication. To consent, users sign a message provided by an Authentication server, instead of using a username and password combination. We use the owner of the domain as the public key that is recovered.

The Authentication server should use the AMR Value of uns-own.

Record-based authentication

For domains owned by multisig wallets, owner-based authentication isn’t sufficient for authentication because there is no private key associated with the owner account. To solve this problem, domains can specify a private key as a record on the domain.

Ethereum Address

The below fields are used to specify a public key that can be used for authentication.

info

It’s recommended that DApps support the web3 and oob methods at a minimum.

Field Description
user The OPTIONAL user of the account. If one was resolving this information on domain.tld, the webfinger resource constructed would be acct:user@domain.tld. If no user is present in the record, the account would be domain itself, i.e. acct:@domain.tld.
addr An Ethereum address corresponding to a private key a user owns.
addrtypehint An OPTIONAL hint for the Authentication server to suggest sign-in methods. If no hint is present the Authentication server should display as many methods as it can support.

For context, addrtypehint can have the following values:

Value Description
web3 Signing done via Injected web3 instance
trezor Signing done via Trezor Wallet. This method is considered uns-hwk.
ledger Signing done via Ledger Wallet. This method is considered uns-hwk.
walletconnect Signing done via Wallet Connect Modal
walletlink Signing done via Wallet Link Modal
mewconnect Signing done via My Ether Wallet Connect, used by their Mobile app
formatic Signing done via Formatic Wallet
portis Signing done via Portis Wallet
oob Signing done via Out of Band signing. Authorization server should have a message to sign displayed and have a form for the user to paste the signature for authentication.
info

If the Ethereum account is stored using a hardware wallet, the AMR Value SHOULD be uns-hwk. For all other address types, the Authentication server should use the AMR Value of uns-swk.

JWKS by Value

The Authentication Server should use the AMR Value of uns-swk.

Field Description
user The OPTIONAL user of the account. This is interpreted in the same way as it is in the “Ethereum Address” flow.
jwks A JWKS document stored in plaintext containing the signing key(s) used to prove the identity of the End-User

Example: Authentication Web3 domain Records

Those records would correspond to the user alice@domain.tld.

Copy
Copied
{
	“authentication”: {
	“alice”: “{\“addr\”:\“0x1234567890123456789012345678901234567890\”,\“addr_type_hint\”:\“web3\”}”,
“bob”: “{\“jwks\”:\“{\“keys\”:[...]}\”}”,
“charlie”: “{\“jwks_uri\”:\“ipfs://Qme7ss3ARVgxv6rXqVPiikMJ8u2NLgmgszg13pYrDKEoiu\”}”
}
}

JWKS by Reference

The Authentication Server should use the AMR Value of uns-swk.

Field Description
user The OPTIONAL user of the account. This is interpreted in the same way as it is in the "Ethereum Address" flow.
jwk_uri URL of the JWKS document containing the signing key(s) used to prove the identity of the End-User

Introspective Access Token Validation

Access tokens are put into an authorization header using the “Bearer” authentication scheme with the following format:

Copy
Copied
Authentication: "Bearer " + Base64<username + ":" + token_id>

username = The subject of the access_token
token_id = The token returned from the token_endpoint earlier

This scheme is very similar to the Basic Authentication scheme, but for compatibility purposes, the token is opaque and therefore a Bearer token.

Additional Standards & Resources

The Authorization server supports several standards beyond Authentication and Authorization explained in these docs.

+The OIDC Consortium hasn’t formally audited these features offered by the server.