Discovery

23.1

Before the app can redirect to the authorization server, the app needs to know which authorization server to direct the user to! This is because each user is identified by a URL, and the user’s URL indicates where its authorization server lives.

The app first needs to prompt the user to enter their URL, or obtain their URL some other way. Typically apps will include a single URL field for the user to enter their URL.

The app will make an HTTP GET request to the user’s profile URL, looking for either an HTTP Link header or an HTML <link> tag with a rel value of authorization_endpoint. In the case that the client is also trying to obtain an access token for the user, it will also look for a rel value of token_endpoint.

For example, a GET request to https://aaronparecki.com/ may return the following, shown as an abbreviated HTTP request.

HTTP/2 200
content-type: text/html; charset=UTF-8
link: <https://aaronparecki.com/auth>; rel="authorization_endpoint"
link: <https://aaronparecki.com/token>; rel="token_endpoint"
link: <https://aaronparecki.com/micropub>; rel="micropub"

<!doctype html>
<meta charset="utf-8">
<title>Aaron Parecki</title>
<link rel="authorization_endpoint" href="/auth">
<link rel="token_endpoint" href="/token">
<link rel="micropub" href="/micropub">

Note that the endpoint URLs may be relative or absolute URLs, and may be on the same domain or on a different domain than the user’s endpoint. This allows the user to use hosted services for any component.

More details on discovery can be found at
https://indieauth.spec.indieweb.org/#discovery-by-clients.