2020/Pop-ups/IndieAuth

From IndieWeb


IndieAuth 1.1 is a IndieWebCamp Pop-ups 2020 session.

IndieWebCamp Pop-ups 2020
Session: IndieAuth

When: 2020-08-08 9:30 AM (Pacific) / 12:30 PM (Eastern)
URL: https://events.indieweb.org/6xlxgeCEMgv8
Video: ▶️2:34:20s

When: 2020-08-22 9:30 AM (Pacific) / 12:30 PM (Eastern)
URL: https://events.indieweb.org/uCtG38aoJyju
Video: ▶️1:50:40s

Streaming video/audio platform: Zoom

Let's discuss how can we iterate IndieAuth? What open issues are there to discuss on the issue tracker? What OAuth proposals might be worth implementing in IndieAuth endpoints? Should PKCE be mandatory? More thoughts captured in the IndieAuth 1.1 milestone on GitHub.

If possible, attendees should familiarize themselves with existing open issues.

Organizers

Interest

Add your +1 for interest in this topic:

Participants

Notes from 2020-08-08

https://github.com/indieweb/indieauth/milestone/1

Include user profile information in response

  • Include user profile information in response https://github.com/indieweb/indieauth/issues/41
    • Earlier discussion also important: https://github.com/indieweb/indieauth/issues/31
    • Instead of having to parse for an h-card which can be finicky/flakey depending on setup
    • The profile data is not guaranteed to be verified in any way. It is what the user chooses to provide to the application for display purposes only. Definition of profile data and its authoritative nature has to be added to the spec.
      • For example, if email is included in the profile information, it *should not* be used to associate this users with a user profile in another system.
    • Existing producing implementations: WordPress, Drupal, p3k, micro.blog, imoxia.com, tonyburns.net via Singulus
    • Plan to add: Rosemary Orchard, Jacky Alciné via Koype, Koype/Publish, Lighthouse and Lwa, Martijn van der Ven in Sink
    • Existing consuming applications: Quill, Publ, Indigenous (https://github.com/indieweb/indieauth/issues/31#issuecomment-589521727)
    • First URL is the identifier (e.g. on micro.blog, it's the URL the user entered when logging in with indieAuth)
    • The auth provider could offer the abiility to change what data is provided on the fly (e.g. change your name to "Jacky the Conquerer") - as done by Apple with Sign in with Apple.
    • Scopes: profile, email,
      • What would a profile scope return, as there is basic profile info returned by default? Or would some endpoints want it for everything?
    • Multi-user websites may return the same "me" URL (e.g. microformats.org) but depending on the admin who's logged in the profile info would be different
    • The "profile" section is specifically providing details about the user authorizing the request, and may not be the same as the "me" URL

Allow the 'me' parameter to authorization endpoints to be omitted

  • Allow the 'me' parameter to authorization endpoints to be omitted? https://github.com/indieweb/indieauth/issues/19
    • General consensus to drop, and leave standalone implementations up to people if they want to do that
    • It is possible to do a standalone implementation by either unique endpoints per user (e.g. how Aperture provides unique Microsub endpoints), or encoding data in the authorization code itself

Drop specification for communication between authorization and token endpoints

  • Drop specification for communication between authorization and token endpoints https://github.com/indieweb/indieauth/issues/44
    • +1 from David Shanske for moving the definition of independent endpoints on a wiki page somewhere, but not citing it in the IndieAuth spec as an extension.
    • An extension would need to define the stuff removed in #19 in order to do this
    • Aaron Parecki has no interest in creating this extension and plans on discontinuing tokens.indieauth.com anyway

Consolidate authentication and authorization sections

  • Consolidate authentication/authorization sections because they are actually the same https://github.com/indieweb/indieauth/issues/42
    • And also drop response_type=id and make it match OAuth using response_type=code
    • Micro.blog already ignores response_type
    • Add a compatibility note about some old clients including response_type=id and how to handle that
    • Authorization servers do want to be able to show a different UI to users depending on whether an access token will be issued (e.g. authorization vs authentication), but that can still be done by looking at the scopes requested

New Features

  • Adopt PKCE https://github.com/indieweb/indieauth/issues/39
    • PKCE RFC: https://tools.ietf.org/html/rfc7636
    • https://indieweb.org/PKCE
    • Clients and servers can start adding this today because of the way it's written as being backwards compatible
    • Require S256 algorithm
    • Depends on removing the token-auth endpoint communication (or extending it to include PKCE)
    • Depends on consolidating the authn/authz sections into one section
    • For now, IndieAuth servers will need to support non-PKCE clients. If the auth code request contains a code_challenge then the token request MUST include code_verifier. If the auth code request does not contain code_challenge, the token request MUST NOT include a code_verifier.
  • Putting the Bearer in the X-Auth-Token Header David Somers [omz13]
    • Some HTTP servers and proxies strip the Authorization header
    • Some HTTP servers only pass through an explicitly allowed list of headers
    • Logging systems often block certain known headers from being logged e.g. the Authorization header, using an alternative name would prevent avoiding writing it to logs
    • A workaround is to have your web server translate the Authorization header into another name before it hits your backend, no client changes needed
    • Some servers already provide the Authorization header as different environment variables by the time it hits your code, e.g. "REDIRECT_HTTP_AUTHORIZATION"
    • Conclusion: there is nothing we can add at the spec level to guarantee a more reliable experience since any combination of these options are still highly dependent on individual hosting environments
  • Add option prompt=login inspired by OpenID connect?
    • Specifically this provides a mechanism for the client to request that the user authenticates rather than is immediately redirected
    • There is a difference between the client requesting this and the server enforcing it. The server can already enforce this for risky scopes or requests without any spec change needed.
    • Most clients probably shouldn't be requesting this, because it is specifically only for when clients need additional assurance of the user having recently authenticated. It will lead to a worse UX since users will need to authenticate again.
    • Need to do some research on this, and revisit after some of the other changes are made

Pushed to next time

Notes from 2020-08-22

Attendees

Issue 41 - Profile Info

  • scopes: profile - name + photo, email - email
  • response_type=id replaced...should assume if no scopes require a token, it is an ID request. Section 5.2 needs to be rephrased.
  • scope is a request from the app to the AS, the AS can always issue scopes the app doesn't request based on its own policies. apps always have to be able to handle getting back different data than they request.
  • no scope == only user's URL is returned
  • profile == user's URL + name + photo
  • email == email (could be used for account recovery for example)
  • create/update/etc (micropub scopes) == access token
  • define these scopes in the spec, and point to indieweb wiki as a place to find other scopes (maybe here https://indieweb.org/scope)
  • account recovery use case: ask for email, but if the app doesn't get email, then it can give the user some recovery codes. Wiki should have a page on the topic of account recovery methods.
    • Can WebAuthn be used for recovery or should it be part of scope? Yes and no:
      • 1 A site (IndieAuth Provider) can itself use WebAuthn for authenticating the user as part of an IndieAuth sign-in request from a IndieAuth CP, e.g. instead of email/pw, or Apple sign-in etc.
      • 2 It makes no sense for WebAuthn to be part of any requested scope because WebAuthn credentials are per-site (per consuming site) and thus the provider would not be able to provide any useful WebAuthn credential for use by another site.
      • 3 However a CP could, once a user has successfully signed in with IndieAuth, prompt the user to add Account Recovery via WebAuthn to their account on that CP. Note that would be a separate (optional) user-flow, after a successful IndieAuth sign-in, potentially something that the user could enable (disable / change) at a much later time if they chose to.

Issue 39 - PKCE

  • PKCE waiting on other merges, but is otherwise decided on.

Issue 19 - Allow me parameter to auth endpoints to be omitted

  • Proposal to make me parameter optional in an initial request. If it is optional, it will simplify and allow greater OAuth2 capability
  • Suggest that reasons why the optional parameter SHOULD be sent should be documented in the spec.
  • Mention use cases for when the AS might want to use the `me` value
    • indieauth.com use case
    • someone can have multiple micro.blog domain names, without the parameter it would have to show a list of domains or use a default one, with the parameter it can choose the right one earlier

Issue 36 - Ambguity in Handling Redirections

https://github.com/indieweb/indieauth/issues/36

Issue 53

https://github.com/indieweb/indieauth/pull/53

  • TODO: Note that the extra verification applies only if the original and current profile URL do not match EXACTLY.
  • This could allow removal of the same domain return requirement in 5.3.2 and allow for multiple identities being linked, but this would be a separate issue.
  • TODO: open new issue to talk about removing the same-domain check once the auth endpoint check is in place
  • add another sentence to https://github.com/indieweb/indieauth/pull/53/files#diff-e5fe492096c54e1b1f5f3290055a2660R635 to make sure clients don't allow the profile URL to change again (ignore the profile URL bits in the discovery section)
  • TODO: follow both temporary and permanent redirects when rediscovering the authorization endpoint

Issue 33 - Support OAuth2 Introspection

  • Already can experiement with adding this to the token endpoint because OAuth introspection is a POST and IndieAuth is a GET
  • Need information on whether existing OAuth libraries would even be compatible with the IndieAuth introspection response
  • Would existing OAuth libraries need updating in order to handle the IndieAuth response
  • TODO: Call out expiration (expires_in or exp/expires_at) in the IndieAuth response if the token expires

Issue 43 - Consider Using OAuth Server Metadata

  • Good to have, but only if we have features that require it and therefore also premature, see #40

Issue 40 - PAR

  • Marginal benefit right now, unless more gets added to the authorization request (e.g. account numbers, identifying or personal information)
  • Premature to adopt any specific OAuth extension draft?
  • If we do find that we may want to add things to thet authorization request that are "sensitive" then it's worth revisiting this
Retrieved from "https://indieweb.org/wiki/index.php?title=2020/Pop-ups/IndieAuth&oldid=72396"