Re: WebID-OIDC - Authentication question

Alexandre had originally talked about a service to factor out processing of id_tokens.

In the case of the “bearer tokens” currently being used, I had wanted to wait for https://github.com/solid/webid-oidc-spec/pull/27 to be merged before raising my concerns in an Issue.  However, since Michiel mentioned them here, and there is a chance a significant effort could be undertaken by Alexandre and others to implement a bearer token validation service, I think it’s prudent to mention my concerns.

I believe there are substantial and significant security issues with the currently implemented (with documentation waiting to be merged) Proof-of-Possession bearer token authorization scheme.  The most important ones are:

* the client creates and issues the bearer tokens with no input from the resource server (or its authorization infrastructure). In general, the client has no standing in the OAuth model to create or issue an access token. This is incompatible with the kinds of OAuth infrastructure likely to be deployed in enterprises.
* there’s no reasonable way for the resource server (or its authorization infrastructure) to revoke one of these tokens.
* the validity period (nbf, exp) are solely under control of the webid’s OIDC Issuer and the client/app, another aspect over which those parties don’t have standing. The resource+authorization server is the only party with standing to specify the validity period of its access tokens, which might be shorter or longer than the validity period in any identity proof provided by the client.
* the format of the bearer token is mandated, rather than being up to the resource and authorization servers. This makes it potentially incompatible (or at least non-optimal) with the kinds of OAuth infrastructure likely to be deployed in enterprises.
* there’s no provision for multiple protection spaces (realms) with different security policies at the same origin.
* there’s no way for the resource server to force a current/timely proof of possession of the confirmation key.
* (related) there’s no way for the resource server to directly cryptographically challenge the client (for example, with a salt/nonce).

Also, these proof tokens are necessarily big and must be passed around on every request. HTTP/2 header compression might mitigate that somewhat between a client and a reverse proxy/gateway, but at some point in the processing chain, a multi-K blob of bytes needs to be processed on every request.

Some time ago I proposed an alternative authorization method [1] that addresses these concerns, and even brought it up on a Solid Community Group meeting call [2] requesting discussion. I hope once the pending spec changes are merged we can address this.

  [1]: https://github.com/solid/webid-oidc-spec/issues/25

  [2]: https://www.w3.org/community/solid/wiki/Meetings#20190613_1000CEST


-mike

From: Michiel de Jong <michiel@unhosted.org>
Date: Friday, July 12, 2019 at 2:33 AM

Hi Alexandre,

Yes, you could run a service inside your network that is trusted by your other services to parse and validate the bearer token.
You could for instance implement that bearer-token-checker service in NodeJS, using https://github.com/inrupt/wac-ldp/blob/master/src/lib/auth/determineWebIdAndOrigin.ts#L62 . Our wac-ldp module exposes a function that checks several things:
* which webId does the bearer token claim to prove user identity for
* which origin was that proof of user identity issued to
* was this proof of identity signed correctly by the IDP of the user
* in case an origin header is present (i.e., for web apps), does it match the origin to which the proof was issued

It should be quite easy to run that code in a micro-service, I would be excited to help you set that up!


Cheers,
Michiel.

On Thu, Jul 11, 2019 at 4:47 AM Alexandre Bourlier <alex@startinblox.com<mailto:alex@startinblox.com>> wrote:
Hi Dmitri,
Hi everyone,

We are implementing the WebID-OIDC spec to authenticate our users.

We currently have two applications that we would like to authenticate via WebID-OIDC :
 - the JS app that is running in the browser
 - the Prosody XMPP server
and probably more to come. This forces us to replicate steps 6 and 7 of the spec wherever the `ID token` validation happens.

My question is : is it OK to implement a web service that will allow us to factorize this code ?

We could call that web service, passing it the `id token` and any relevant parameters, and it would respond with the `webid` if the token was valid, or with an explicit error message if it wasn't.
Sounds like a good idea to be but I might be missing something.
Your validation that this architecture would work and be WebID-OIDC compliant would help us decide in which direction we go.

All the best !

--

Alexandre BOURLIER
06 51 71 08 21
https://happy-dev.fr

https://startinblox.com