User:Martymcgui.re/IndieAuth-Endpoint-Testing

From IndieWeb

Goals

a test suite to verify the implementation of IndieAuth authorization endpoints. And token endpoints. maybe at indieauth.rocks?

Guidance

Don't have any state. or logins. or ways a test could be used to attack ppls sites.

Spec details to test

Authorization Endpoint

Definition: https://indieauth.spec.indieweb.org/#x2-1-1-authorization-endpoint

An IndieAuth Authorization Endpoint is responsible for obtaining authentication or authorization consent from the end user and generating and verifying authorization codes.

Authentication Flow

Auth Request

Check for query components. 400 if any are missing

  • client_id
  • redirect_uri
  • state

Auth Endpoint SHOULD resolve client_id as a URL and fetch it to look for allowed redirect_uri values. Test cases:

  • client_id and redirect_uri are on the same domain (technically fetching the client info is optional in this case?
  • client_id and redirect_uri on are different domains (auth endpoint must fetch the canonicalized URL for client_id and look for allowlisted redirect_uri values):
    • Link rel=redirect_uri HTTP header
    • <link rel="redirect_uri" ...> in HTML head.
    • sub-cases:
      • redirect_uri is in the discovered list - succeed and continue to authentication
      • redirect_uri is not in the discovered list - fail (400? or other?)
URL Canonicalization

https://indieauth.spec.indieweb.org/#url-canonicalization

Probably not many testable cases for an authorization endpoint other than resolving client_id.

Authorization Screen

List of things to show about a client:

https://indieauth.spec.indieweb.org/#client-information-discovery

(hard to test if this actually shows since every auth endpoint will have a different authentication mechanism)!

Things to show:

  • redirect_uri - no matter what, this should be shown!
  • client_id
  • if fetched and parsed h-app from client_id:
    • name
    • logo
    • url (what if different from client_id?)

Depending on the request type (id vs code):

  • what the app wants
    • in the id case, it wants your me URL
    • in the code case, it wants your me URL + scopes
Authentication Response

If user accepts request, auth server should:

  • redirect to redirect_uri
  • with same state value it received in the authentication request
  • and a code
    • this code should be short lived with recommended max 10 minute lifetime. testing this will require actually waiting. ๐Ÿ˜‚
Auth Code Verification

Client POSTs to auth endpoint with the code and gets back me value.

Auth endpoint should 400 if any of these are missing:

  • code
  • client_id
  • redirect_uri

auth endpoint should fail the request (not sure HTTP response code) if:

  • code is not recognized as one issued by the auth endpoint
  • client_id does not match the one from the initial auth request
  • redirect_uri dose not match the one from the initial auth request

if everything checks out, auth endpoint should:

  • respond with application/json
  • containing an object
  • with a me property
  • containing the canonical user profile URL for the user who signed in
  • which must be on the same domain as the initial me value in the initial authentication request.

Authorization (Token) Flow

https://indieauth.spec.indieweb.org/#authorization

tbd

Token Endpoint

An IndieAuth Token Endpoint is responsible for generating and verifying OAuth 2.0 Bearer Tokens.

tbd

Resources

Brainstorming

Authorization Endpoint Testing

Some things can be tested with a single GET or POST from the server:

  • 400 fail on missing auth requests params (client_id, redirect_uri, state)
  • 400 fail on missing code verification params (code, client_id, redirect_uri)
  • fail (what code?) on unrecognized code (just make up a code, client_id, redirect_uri)

Some things will require human intervention

  • can't automate the actual authentication step at the auth endpoint
  • can't automate testing what the authorization screen displays
  • can't automate accepting or rejecting

Can automate verifying that auth endpoint fetches client_id URL

  • e.g. indieauth.rocks/indieauth-client/TEST-IDENTIFIER
    • things that we need to know:
      • the auth endpoint under test
      • what redirect_uri info to include and where (HTTP header vs HTML head)
      • what h-app info to include (if any)
    • if we don't want to save state, we could encode these things into the URL itself as part of the TEST-IDENTIFIER or as other query components?

Can automate verifying that auth endpoint redirects user back with proper code stuff

  • e.g. redirect_uri redirects back to indieauth.rocks/indieauth-client/redirect/TEST-IDENTIFIER
    • can check for standard oauth2.0 access_denied, etc.
    • to verify that an auth endpoint will allow a redirect_uri to a different domain than indieauth.rocks - we'd also need this to run on a second domain! or subdomain. like other-domain.indieauth.rocks.
    • again, test identifier could encode the values we are expecting
    • could also store useful things in browser cookies, since full-path testing will require a human-with-a-browser-in-the-loop. e.g. state
    • this is also the point where we could test code verification:
      • send the wrong client_id or redirect_uri