Closed aaronpk closed 2 years ago
Being as we specify the authorization endpoint URL as a rel parameter now, I would vote for the 1st one, exact match.
FWIW my implementation has set ISS to "minter@endpointserviceusers.iam.gserviceaccount.com" which is the service account signing the token. Do you need to describe what it is beyond an opaque token?
(see https://observablehq.com/@endpointservices/weblogin)
My iss
would be the #43's issuer
field, which is (currently) the IndieAuth server base URL
My IndieAuth server now returns this, i.e.:
https://monocle.p3k.io/login/callback?code=drsEIwCi0Xs0kl9DC0DI&iss=https://indieauth.jvt.me&state=67b462411623242b
{
"code": "drsEIwCi0Xs0kl9DC0DI",
"iss": "https://indieauth.jvt.me",
"state": "67b462411623242b"
}
Closing, as this is now adopted by #102.
The OAuth Security BCP is adding the recommendation of using the
iss
parameter described in OAuth 2.0 Authorization Server Issuer Identification. This parameter helps avoid certain mixup attacks when an OAuth client interacts with multiple authorization servers.Since IndieAuth clients by definition interact with multiple authorization servers, it makes sense that we should consider adopting this as well.
According to that draft, if we don't support OAuth Server Metadata where
iss
is defined, (#43) then we would have to create our own definition of theiss
value. Some options that are relatively straightforward would be:iss
value (differing from most other OAuth servers today)iss
value, e.g. for an authorization endpointhttps://example.com/auth
theiss
value would behttps://example.com/
This value is expected to be checked by the client, so it needs to be as simple as possible for the client, so I would rather use a method that doesn't require actually parsing the URI. Method 1 above would be a straightforward exact string match. Method 2 could be accomplished by checking that the
iss
value is a prefix of the authorization endpoint rather than doing anything with URI parsing.