Proposal: a protocol to obtain Bearer access tokens for HTTP Authorization for the AJAX/API/bot use case

[zenomt]

the example-workflow.md document leaves unspecified how an application or automatic client (like an in-browser AJAX client where no cookie exists or can be used, or a server-side application with its own WebID (like a bot)) obtains an access credential when presented with a 401 Unauthorized response from a resource server.

node-solid-server, oidc-op, and oidc-rp together address this case in a currently undocumented (experimental?) way, described in #24. summary: "a proof-of-possession token is manufactured by the client and presented directly as a bearer token".

i'd like to propose an alternative method that is more in line with the spirit of OAuth, and which also uses proof-of-possession. i've (re)written a full protocol proposal at WebID HTTP Authorization Protocol. highlights of this protocol and capabilities it enables include:

• the client must sign a challenge chosen by the resource server to prove immediate possession of the private challenge key;
• the server, rather than the client, chooses the validity period of the access token;
• provides an extensible framework for obtaining access tokens using different authentication mechanisms (for example, the spec includes a method to authenticate and obtain a bearer token using WebID-TLS, but that's beyond the scope of this Issue);
• an optional HTTP 302 redirect-based token delivery mode that can be used to establish an application identifier, especially in case the proposal at Proposal: recommend WebID OpenID Providers include redirect_uri in audience list to distinguish web apps #23 is rejected or not widely implemented (or for WebID-TLS);
• the server (or its authorization delegate) can choose the format/representation/length of the token, for example to fit in with existing authorization infrastructure or to work optimally in the server's implementation;
• the server can revoke its own access tokens trivially;
• the server can require (and manage/revoke) different access tokens for different protection spaces it may serve, consistent with HTTP authorization semantics -- these tokens could be generated and validated by different authorization subsystems running in the server and have independent lifetimes.

summary of the protocol (please see zenomt/webid-auth-protocol for a full description):

1. try to access restricted resource;
2. get 401 Unauthorized, and a WWW-Authenticate response header that includes a challenge nonce and a token-exchange endpoint URI;
3. create and sign a proof-of-possession token that includes the challenge nonce and the URI you were trying to access (and your OIDC identity token);
4. exchange the proof-token for a Bearer access token (with its own expiration time);
5. use this token in Authorization headers for requests to the same protection space, until it expires.

[kjetilk]

Thanks a lot for writing this up! It caused confusion and pain to me as well when starting to write a test suite. I think we need to fix this.

[jaxoncreed]

@sylvainlb This might be interesting to you

[jaxoncreed]

@zenomt When you say "the server, rather than the client, chooses the validity period of the access token;" Is the server the RS or the OP?

[zenomt]

@jaxoncreed the resource server chooses the validity period of the access tokens it issues. the validity period of its access tokens could be shorter or longer than the validity period of the presented proof-tokens. the reasoning is: the access policy of the resource server is up to the resource server, not to the client or the client's OIDC Provider.

[zenomt]

to be more precise, the access token is issued by the webid_pop_endpoint, which is the resource server's authorization server. the resource server could be its own authorization server, or (in some deployments, like enterprise systems) the authorization server could be a centralized service to which multiple resource servers are coupled.

this separation is more obvious with the webid_tls_endpoint, where for it to be useful in the real world it needs to have a different origin than the resource server (so the authorization server can ask for a client certificate). the webid_tls_endpoint authorization server could be a virtual host on the same actual server, or it could be on a completely different server.

[zenomt]

i struck out the "302 redirect" mode above as a "highlight" of the protocol (though it's still present). that mode isn't useful to establish an application identifier with the webid_pop_endpoint. i've modified the spec, including the Syntax, Operation, and Security Considerations sections to explain why. also in the Security Considerations section is an explanation as to why you can't believe the Origin header for any Bearer-type authorization scheme, not just this one.

[zenomt]

unfortunately the minutes from this morning's Solid Community call were lost, and i don't remember who asked about it, but i have added a sequence diagram for the WebID-OIDC access token case to the https://github.com/zenomt/webid-auth-protocol .

[michielbdejong]

Great! It was @bblfish who asked "(Henry) Is there a sequence diagram as part of the spec?"

[TallTed]

@zenomt - It can be helpful to ping the group for anyone who has personal IRC logs (as I would have, were I logged in to IRC at the time) ... or, if RRSAgent was present, to ping W3 admins for help locating the bot's log. W3 admins can usually also help with processing anyone's IRC logs into minutes via the scripts.

[kjetilk]

Ah, I am always on, even if I'm not on present :-) But it seems it is in the minutes? Anything else that was lost?

[zenomt]

i updated my full proposal based on #12 (comment) which is a cleaner method of determining the appid from the id_token audience than i had originally proposed. i'm still proposing that the redirect_uri be the appid and that it is present in the id_token aud list.