'aud' claim in Solid OAuth tokens

[cblakeley]

The aud claim in OAuth tokens issued by Solid appears incorrect and is causing authentication errors when a client supplies the access token.

---

Added 2019-Feb-01:

Added a TLDR re-iteration of the essential problem which triggered this issue, and the proposed fix, here for those not wanting to read the complete thread (though I recommend it, there's a lot of good information courtesy of @dmitrizagidulin)

---

@RubenVerborgh @kjetilk @dmitrizagidulin: Please could you comment?
/cc @kidehen @smalinin

Manifestation

OpenLink are seeing error Token does not pass the audience allow filter when trying to bind a Solid pod to Virtuoso WebDAV using our WebDAV 'DET' functionality.

Recreation

I've been able to replicate the problem, eliminating Virtuoso in the process.

I signed into a local instance of OSDB using solid.openlinksw.com:8444, then while logged in, I retrieved the access token from OSDB's oidc-rp storage.

curl -kIH  "Authorization: Bearer {access-token}" https://cmsblakeley.solid.openlinksw.com:8444/public/

HTTP/1.1 403 Forbidden
X-Powered-By: OpenLink Solid Server
Vary: Accept, Authorization, Origin
Access-Control-Allow-Credentials: true
Access-Control-Expose-Headers: Authorization, User, Location, Link, Vary, Last-Modified, ETag, Accept-Patch, Accept-Post, Updates-Via, Allow, WAC-Allow, Content-Length, WWW-Authenticate, On-Behalf-Of, webid-tls
Allow: OPTIONS, HEAD, GET, PATCH, POST, PUT, DELETE
WWW-Authenticate: Bearer realm="https://solid.openlinksw.com:8444", error="access_denied", error_description="Token does not pass the audience allow filter"
Content-Type: text/html; charset=utf-8
Content-Length: 877
ETag: W/"36d-HJZUCkFVG9xNWz4IGHiCqJijAlc"
Date: Tue, 22 Jan 2019 17:05:34 GMT
Connection: keep-alive

Decoding the oauth token (a JWT) using https://jwt.io/

{
  "iss": "https://solid.openlinksw.com:8444",
  "sub": "https://cmsblakeley.solid.openlinksw.com:8444/profile/card#me",
  "aud": "79888c62ca35e4b89665f328b494600b",
  "exp": 1549385146,
  "iat": 1548175546,
  "jti": "5709a267c48596e8",
  "scope": "openid profile email"
}

The "aud" (Audience) claim matches the clientId under key rpConfig.session.clientId in the oidc-rp data.

Problem Source

(Line numbers refer to OpenLink's forks)
The error comes from: AuthenticatedRequest#allowAudience

@solid/oidc-rs/src/AuthenticatedRequest.js:354

  allowAudience (request) {
    ...
    if (typeof audience === 'function') {
      if (audience(aud)) {
        return  // token passes the audience filter test
      } else {
        return request.forbidden({
          realm,
          error: 'access_denied',
          error_description: 'Token does not pass the audience allow filter'
        })
      }
    }
    ...

Function audience above is a reference to OidcManager#filterAudience

@solid/oidc-auth-manager/src/oidc-manager.js:251

  initRs () {
    let rsConfig = { // oidc-rs
      defaults: {
        handleErrors: false,
        optional: true,
        query: true,
        realm: this.providerUri,
        allow: {
          // Restrict token audience to either this serverUri or its subdomain
          audience: (aud) => this.filterAudience(aud)
        }
      }
    }

    this.rs = new ResourceAuthenticator(rsConfig)
  }

The filter function which is rejecting the aud claim is defined at:

@solid/oidc-auth-manager/src/oidc-manager.js:441

  filterAudience (aud) {
    if (!Array.isArray(aud)) {
      aud = [ aud ]
    }

    return aud.some(a => OidcManager.domainMatches(this.providerUri, a))
  }

The comments for method domainMatches state:

  * Tests whether a given Web ID uri belongs to the issuer. They must be:
  *   - either from the same domain origin
  *   - or the webid is an immediate subdomain of the issuer domain

There's a mismatch between the form of the aud claim in the supplied access token and the form expected by OidcManager#domainMatches, i.e. clientId as opposed to webID. (We confirmed this in-house by adding extra debug output. The aud claim being tested by filterAudience() is a clientId, not a webID).

Fix?

According to RFC7519: JSON Web Token (JWT) - Section 4.1.3 "aud" (Audience) Claim

The "aud" (audience) claim identifies the recipients that the JWT is intended for. Each principal intended to process the JWT MUST identify itself with a value in the audience claim. If the principal processing the claim does not identify itself with a value in the "aud" claim when this claim is present, then the JWT MUST be rejected. In the general case, the "aud" value is an array of case-sensitive strings, each containing a StringOrURI value. In the special case when the JWT has one audience, the "aud" value MAY be a single case-sensitive string containing a StringOrURI value. The interpretation of audience values is generally application specific. Use of this claim is OPTIONAL.

OpenID Connect Core 1.0

In an ID token issued to a client, the aud claim must contain the client_id.

• 2. ID Token

aud
REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value. It MAY also contain identifiers for other audiences. In the general case, the aud value is an array of case sensitive strings. In the common special case when there is one audience, the aud value MAY be a single case sensitive string.

But, in the case of an access token, rather than an ID token, as far as I can see from the OIDC spec' the client doesn't use the aud claim at all when validating any access token it receives.

• 3.1.3.8 Access Token Validation (Authorization Code Flow)
• 3.2.2.9 Access Token Validation (Implicit Flow)
• 3.3.2.9 Access Token Validation (Hybrid Flow)

Given the definition of aud in the JWT spec' ('The "aud" (audience) claim identifies the recipients that the JWT is intended for.'), it seems to me that the access tokens issued by Solid need to be changed so that the aud field includes the iss claim or the sub claim, instead of (or in addition to) the client_id.

[RubenVerborgh]

@RubenVerborgh @kjetilk @dmitrizagidulin: Please could you comment?

I can't comment beyond "that's quite possible" 🙂
Have not written any OIDC code myself.

[dmitrizagidulin]

Ok, so, this is on purpose, and has to do with Solid's extension to OIDC to make it more decentralized (to allow an app to authenticate to multiple unrelated Resource Servers with just one ID token). I'll explain more in another comment, but just wanted to give a heads up.

[kidehen]

@dmitrizagidulin,

What's on purpose? How does this extend decentralization?

[RubenVerborgh]

The filter function which is rejecting the aud claim is defined at:

@solid/oidc-auth-manager/src/oidc-manager.js:441

  filterAudience (aud) {
    if (!Array.isArray(aud)) {
      aud = [ aud ]
    }

    return aud.some(a => OidcManager.domainMatches(this.providerUri, a))
  }

The comments for method domainMatches state:

  * Tests whether a given Web ID uri belongs to the issuer. They must be:
  *   - either from the same domain origin
  *   - or the webid is an immediate subdomain of the issuer domain

I think another question about this then, for @dmitrizagidulin, is whether this check is correct. Why is this checked on audience rather than subject?

Also, this check seems obsolete given the oidcIssuer predicate, because my WebID is on ruben.verborgh.org whereas my pod is on drive.verborgh.org. So the latter is an issuer for the former, but the check would fail.

[kidehen]

@RubenVerborgh,

We have fixed this issue and published a PR.

What next?

[RubenVerborgh]

@kidehen Determining whether that PR is indeed fixing the correct issue; see follow-up in nodeSolidServer/oidc-op#13.

[dmitrizagidulin]

Hi everyone! So, the root cause for this issue is lack of documentation on our part.

The short version is - the access token from oidc-rp's storage (I assume it got there via solid-auth-client) is not something you can use directly for requests to the server. It's meant to be used through the auth client's popTokenFor() method, and is used for Solid's WebID-OIDC protocol, which is a combination of regular OIDC and Proof of Possession tokens.

It is possible to request regular OIDC ID tokens from a solid server (by passing in a popToken: false to the RelyingParty constructor), but by default solid-auth-client requests a different kind of token (for use inside its authenticated fetch logic). And on the receiving end, oidc-rs supports both kind of tokens.

So that's the short version - the audience claim is not what you would expect from an OIDC type access token, and that's on purpose. In the next comment, let's get into the broader context of how one uses PoP tokens, and why we need both types of tokens in Solid.

[dmitrizagidulin]

Ok, so what are these Proof of Possession tokens for?

Normally, OAuth2 and OpenID Connect require that a token is restricted to a particular resource server - that's what the aud: claim is for. This is done for excellent reason - see for example the Bind Tokens to a Particular Resource Server (Audience) section of the OAuth 2.0 Threat Model and Security Considerations spec. In the early days, various identity providers found out the hard way that if you don't restrict the audience, it's way too easy for a rogue resource server to steal the token and use it to impersonate the user on other systems (with other resource servers).

So that's why OIDC requires the aud parameter in its tokens: "aud REQUIRED. Audience(s) that this ID Token is intended for. It MUST contain the OAuth 2.0 client_id of the Relying Party as an audience value."
Here's how audience restriction normally works. Lets say I want to view a protected resource on Solid.community, and I'm using my own pod, dmitri.com (not a real pod) as an identity provider.
In this interaction, the actors are:

Identity Provider (IdP): dmitri.com
Relying Party (RP): solid.community
Resource Server (RS): solid.community

I go to access the resource, solid.community prompts me to authenticate, I indicate that dmitri.com is my pod. Classic OIDC workflow. Notice, btw, that solid.community is acting as both a Relying Party and a Resource Server.
So, solid.community makes a request to my pod, dmitri.com, and says "Please give me a token for this user. It's for my own use".
The IdP issues the token, and restricts the audience of its token only to the RP (specifically, to its client_id). So the token looks something like:

{
  sub: "https://dmitri.com/profile/card#me",  // <- my Web ID
  iss: "https://dmitri.com",
  aud: "https://solid.community",  // (it's actually solid.community's client_id)
  // ... other stuff
}

Makes sense so far, yeah? The token is tightly scoped to one resource server, so solid.community can't secretly take it and impersonate me to some other server (because that other server will check the aud: param, and reject it).

(to be continued)

[dmitrizagidulin]

Ok, so that was an over-simplified example, to illustrate what aud:ience filtering is for -- it's a mechanism to prevent resource servers from reusing your tokens elsewhere. So each Solid server inspects bearer tokens and only allows tokens that were minted with it as the audience.

So, as pointed out previously, in oidc-auth-manager, when the server starts up, the Resource Server portion of its config looks like:

  initRs () {
    let rsConfig = { // oidc-rs
      defaults: {
        realm: this.providerUri,
        allow: {
          // Restrict token audience to either this serverUri or its subdomain
          audience: (aud) => this.filterAudience(aud)
        }
      }
    }
   // ...

(And the filterAudience() function just checks "is this token intended for this server, or its subdomain?"). In other words, the server solid.community will only allow tokens which have either https://solid.community in their aud: claim, or any of its subdomains, liks https://*.solid.community.

Incidentally, the subject has nothing to do with this mechanism, and must not be included -- oidc-op PR #13 cannot be accepted, as it bypasses the whole audience filtering mechanism.

Ok, but back to the original problem -- why was the error Token does not pass the audience allow filter encountered in the first place? Why was the aud: claim of that token not https://solid.openlinksw.com:8444 but instead was 79888c62ca35e4b89665f328b494600b, which was the clientId of whatever web app was using it to authenticate?

So now we're back to Proof of Possession tokens.

(to be continued)

[dmitrizagidulin]

The classic OAuth2 / OIDC workflows were designed for situations where there's only two "trust zones".

For example, say you have a third-party Twitter client app (basically what OAuth was invented for). In this case, the trust zones are: 1) Twitter (playing the role of both the Identity Provider and the Resource Server), and 2) the third party app, playing the role of Relying Party.

Or take the example of typical "social media login", where you can log into some web service using your Github account. There's still only two trust zones - Github is playing the role of the IdP, and the web service is playing the role of both the Relying Party and Resource Server. And similarly, in our simplified dmitri.com / solid.community example above, the latter played the role of both RP and RS.

The reason I bring these examples up, is to point out that the audience filtering is only useful for situations when the IdP knows which Relying Party/Resource Server the token is intended for. Or to put it another way, audience filtering is only practical when either the IdP issues tokens for itself (like with the Twitter client app example), or when the RP is also the Resource Server (so it knows to ask for a scoped token for its own use).

But the unique challenge that Solid apps face (not encountered in the traditional OIDC world), is that a Relying Party has to interact with an arbitrary amount of Resource Servers outside its trust zone.

Consider a Solid-style DecentralizedTwitter app. I go to use the app. I authenticate to it (selecting dmitri.com as my pod / identity provider). But now the app has to deal with potentially hundreds of other pods (of people whose feeds I follow)! So instead of two trust zones, we're dealing with N+2 -- the IdP, the app, and N independent Resource Servers.

So this is the main thing differentiating Solid's WebID-OIDC authn protocol from regular OIDC. The necessity to deal with an arbitrary amount of independent resource servers.
Just to be clear, each Solid pod is a classical OIDC OP (identity provider), so it can request and accept regular OIDC style ID tokens (where the RP/RS is known in advance).

But how do we deal with the decentralized twitter use case? Let's zoom in.

We have the user's pod, playing a traditional IdP role. No problem there.

Then we have the DTwitter app, which is the Relying Party. (Actually, it's technically something new, in this situation, it's a presenter role, but ignore that for now.)

And then we have N Resource Servers, different domains and trust zones from the pod or the app.

So the app has to make authenticated requests to those N Resource Servers. And each request has to carry a token that is audience-bound only to that server.

What are our options?

We can't not include an audience binding. Meaning, imagine there was a way for the app to say "hey pod, please give me a general-purpose ID Token that's good for any resource server". That would be really simple, but also wildly insecure, since any of those resource servers could then take that token and pretend to be the user (since there's no audience binding).

Should we then require that for each new Resource Server request it makes, the app should go through the auth flow with the identity provider? (to request a token bound just to that RS?). So like, if I follow Alice and Bob on my DTwitter feed, should the app request "pod, please give me a token bound to Alice.com" and also "Oh and now give me a token bound to Bob.com"?
Well that clearly is not going to work, that's wayy too many round-trip flows.

So, this is the design space and requirements in which WebID-OIDC was developed.

(to be continued tomorrow.)

[kidehen]

@dmitrizagidulin,

What are the implications of the fix that @cblakeley submitted? Do you concur with the fix? Or do you concur with claim by @RubenVerborgh that said fix addresses a symptom rather than baseline problem?