what is this?

An OAuth2 authorization server for communicating with etsy.com implemented in MirageOS. Etsy's authentication flow may be similar enough to other OAuth2 resource servers to make this server useful for them as well.

TLS is provided via Let's Encrypt. Credentials are stored in a separate Chamelon data store and automatically renewed when required.

what's weird about it?

Most systems using OAuth2 in this way have some sort of local authentication which is then connected to a remote system's authentication information as a form of identity federation. This server has no notion of local identity and merely serves as an intermediary for access to the resource server. Authentication requests to Etsy are differentiated by 128-bit random numbers, which are generated by the authorization server and presented to the client. Guessing the random number yields access to the tokens.

This server is a low-effort proof-of-concept implementation, and as such probably responds in unhelpful ways to lots of inputs.

There is currently no rate-limiting on requests, which might give the potential user some pause when combined with the first item in this list. Given an adequate entropy source and CSPRNG, states shouldn't be guessable. The more likely problem is the ease of resource exhaustion attacks, since storage is allocated for each new state and, in the default configuration, not removed for many days.

what's implemented?

endpoints and their happy paths

• /auth : POST uuid=16randombytes
  • server generates and stores a new state and accompanying PKCE verifier
  • server redirects the client to Etsy's oauth/connect endpoint with state, code_challenge, etc
• /etsy : GET ?code=etsycode&state=somestate
  • server retrieves the PKCE verifier for somestate
  • server stores etsycode for somestate
  • server initiates a token request to Etsy with etsycode and the PKCE verifier for somestate
  • server stores the access_token and refresh_token for etsycode and somestate
• /token : POST state=somestate
  • server retrieves access_token for somestate
  • if access_token is too old, server gets a new one with refresh_token
  • if access_token is still valid, server gives it to client

what's not implemented, but hopefully someday will be?

• quicker garbage collection of states that never receive a valid code
• rate limiting
• a nice service on port 80 that redirects you to the TLS server
• user-friendly HTTP bodies for browser rendering
• useful errors in responses for bad state
• any kind of storage optimization

what do I need to run this?

• an Etsy developer key
• a publicly-registered FQDN corresponding to a public IP where you can run a unikernel
• a registered callback URI for your application corresponding to the above FQDN with the /etsy endpoint
• two block devices formatted for Chamelon data storage
  • a small one for credentials (mine is 16K) with your developer key saved at /keystring
  • a larger one for state, code, token, etc. storage

Several targets are provided for convenience in the included justfile. Users will want to make substitutions in the initial variable definitions, particularly fqdn, as appropriate.

AGPL? WTF?

If you want a release of this under a different license, feel free to contact the e-mail address in the commit messages associated with yomimono to arrange something.