Re: WebID-OIDC - Authentication question

Michiel, Michael,

Thank you so much for your responses.
I discovered what PoP Tokens were, and I have now a better understanding of
where we are at, and what needs to be done to have a robust implementation
of the spec, as well as what is missing in the spec.

For now, we will implement an `ID token` validation endpoint, knowing the
limitations we are facing on the security front.
We actually have written most of it already, it is in Django though.

Looking forward to be able to sit on a more robust library security-wise.
We will contribute as much as we can.

All the best !

On Fri, 12 Jul 2019 at 20:33, Michael Thornburgh <mthornbu@adobe.com> wrote:

> 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>
> 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
>
>
>
>

-- 

Alexandre BOURLIER
06 51 71 08 21
https://happy-dev.fr <http://happy-dev.fr>
https://startinblox.com