interledger / rfcs

Specifications for Interledger and related protocols
https://interledger.org
Other
454 stars 111 forks source link

Propose HTTP Auth Recommendations #559

Closed sappenin closed 4 years ago

sappenin commented 5 years ago

Replaces and enhances the work done as part of https://github.com/interledger/rfcs/pull/531

sappenin commented 5 years ago

I've updated the PR to soften the language around the SIMPLE profile. I think it's sufficient to keep the RFC to "tradeoffs" and allow any two peers to decide which of the three profiles to use. Feel free to call out anything I missed in this regard.

sappenin commented 5 years ago

Is there scope to include a profile that is more like OAuth 2.0. i.e. the token is opaque but it is not "pre agreed" between the parties.

@adrianhopebailie I tried to limit the spec to only normalizing "authentication" claims in JWTs, but also tried to leave room for any other claims if desired (e.g., authorization claims). Speak up if you think something is missing, but any of the tokens (well, the JWT's at least) should be usable in an OAuth 2.0 flow.

adrianhopebailie commented 5 years ago

@sappenin I wasn't looking to include other claims but rather change the way you describe the SIMPLE profile.

I think this may also make @emschwartz and @sharafian happier.

Basically, OAuth allows the access token to be either a "handle" (opaque) or something like a JWT which encodes the data.

When a resource server gets a request carrying the token it performs "introspection" to determine things like the subject, expiry, audience, scopes etc of the token.

Introspection can mean:

  1. querying the auth system for the details using the token as the lookup value, or
  2. it could mean decoding and validating the JWT

Out of interest, the OAuth provider we have used for our POC does not use JWT's as access tokens, it uses an opaque token and has some security reasons why they recommend that but I can't find those docs right now!

So, perhaps we can describe SIMPLE as something else that is more along the lines of an "opaque token plus introspection" and then provide guidance on the issuance of the token such as setting an expiry?

adrianhopebailie commented 5 years ago

Found the link: https://www.ory.sh/docs/hydra/advanced#json-web-tokens Thanks @matdehaast

sappenin commented 4 years ago

Closing this in-favor of https://github.com/interledger/rfcs/pull/565

HTTP Auth is now a proposal in the /proposals folder per the new CONTRIBUTING guidelines.