SSO; single api server, multiple client applications

[jeffreylo]

Support for one-of might be an interesting path forward but I'm also curious whether keratin/authn-go#15 also solves your issue?

One advantage to SubjectFromWithAudience is that it doesn't need to be pre-configured with a finite set of audiences at startup.

I'll close this issue on authn-server as it appears to be related to authn-go. Let's continue over there if you think there's more to discover.

Continuing the discussion from keratin/authn-server#193, client JWTs seem to only have a single entry in their aud field, i.e., the requesting domain. This means that SubjectFromWithAudience is still insufficient.

For example, given these identity tokens:

{
  "aud": [
    "client1.example.com"
  ],
  "auth_time": 1643740180,
  "exp": 1643743780,
  "iat": 1643740180,
  "iss": "https://auth.example.com",
  "sub": "1"
}

{
  "aud": [
    "client2.example.com"
  ],
  "auth_time": 1643740180,
  "exp": 1643743780,
  "iat": 1643740180,
  "iss": "https://auth.example.com",
  "sub": "1"
}

There seems to be no clear way to configure the authn-go client’s Audience or leverage SubjectFromWithAudience to pass validation. A jwt.Audience{} in SubjectFromWithAudience would work, but obviously drops audience verification, which seems important.

The proposal for oneOf in #14 seems to best fit this use case, but I’m not sure if there’s a way to accomplish this with the resultant SubjectFromWithAudience shipped in #15.

Does this make sense?

[cainlevy]

I'm missing something here. Is the problem that your backend is unable to determine if the request is coming from client1.example.com or client2.example.com?

[jeffreylo]

I'm missing something here. Is the problem that your backend is unable to determine if the request is coming from client1.example.com or client2.example.com?

More or less, but this seems like an issue unrelated to authn-go’s scope.

For now, I’ve configured an allowlist of known audiences and it works as expected.

Closing as there’s no clear action or next discussion.

[cainlevy]

Allowing all of your potential domains sounds right to me.

You might also be able to rely on the Origin header to reflect the domain of your request, assuming they're all cross origin requests. That's how AuthN sorts out which audience to give an identity token.