Comments (4)
Why would you want multiple audiences at the point of verification? The way i see it, you might need multiple audiences at the point of issuing (i.e. producer/issuer supports multiple consumers/audiences), but the service that verifies is the audience, right? So that service just needs to be one of the issuer audiences. The code looks fine to me regarding that, unless I'm missing something big...
It depends on whether you are thinking about OAuth2 or OpenID Connect (our use case). In the former, where the JWT is an access token, the service that verifies the token is the audience. But in the latter, it may not be (and in our case, it is not). Because in OpenID Connect you also use have JWT tokens for Authentication (when using ID Tokens). And in that case, multiple different Relaying Parties[1] may use the same OpenID Provider [2].
This is exactly our case. We have three Relaying Parties: a mobile app, embedded hardware and a single page application. We have them as three separate Relaying Parties because we want to restrict the allowed authentication and authorization flows depending on the type of client. E.g., embedded devices can't use Authorization Code flow, only implicit flow. But we don't want to enable implicit flow in the other two cases. So we have three relaying parties, each with its own client_id
value (hence, their own aud
value in the ID Tokens issued by the OpenID Provider).
But all of them use their ID and Access tokens with the same REST service. So we need to be able to validate ID and Access tokens with three different aud
values. Probably this is not a very common case, but it's exactly what we are doing in several of our projects. We routed around this "limitation" in our code since the beginning, but it makes the validation slower due to having to catch the exceptions, etc.
[1] OAuth 2.0 Client application requiring End-User Authentication and Claims from an OpenID Provider, from https://openid.net/specs/openid-connect-core-1_0.html#Terminology
[2] OAuth 2.0 Authorization Server that is capable of Authenticating the End-User and providing Claims to a Relying Party about the Authentication event and the End-User, from same URL as note [1]
from buddy-sign.
Hi @serioga
This feature has existed since at least version 2.0.0. The documentation doesn't state it explicitly, but both iss
and aud
claims can be a collection of values.
So maybe the issue should be about updating the documentation to reflect the code behavior 😃
from buddy-sign.
Sorry, my bad. I read the code wrong 😞 The code allows for a collection of audiences in the token itself, not in the verification claims. The original issue still stands.
from buddy-sign.
Why would you want multiple audiences at the point of verification? The way i see it, you might need multiple audiences at the point of issuing (i.e. producer/issuer supports multiple consumers/audiences), but the service that verifies is the audience, right? So that service just needs to be one of the issuer audiences. The code looks fine to me regarding that, unless I'm missing something big...
The documentation improvement definitely stands though 👍
In other words, assuming two generate
(producer) and verify
(consumer) functions, here are the params they could take:
{:generate {:issuer "com.foo.auth" ;; single issuer (identification)
:audiences ["foo-auth-service"] ;; can address multiple audiences
:ttl-max-hours 3} ;; max-age (allows clients to ask for custom exp)
:verify {:issuers ["com.foo.auth"] ;; can verify against multiple issuers
:audience "foo-auth-service" ;; single consumer (identification)
:leeway 15}}
from buddy-sign.
Related Issues (20)
- Is ES384 omitted purposefully? HOT 6
- Supporting custom headers HOT 3
- `iss` validation should be against a collection ("whitelist") HOT 2
- Support for looking up public keys via OIDC discovery HOT 19
- Handle java.security.SignatureException for JWS applications HOT 1
- Where is jws/to-timestamp? HOT 1
- EdDSA JWS support HOT 1
- JWS ECDSA Signatures are generated in incorrect format HOT 2
- New release? HOT 1
- JWT signatures invalid according to jwt.io website HOT 2
- 2.* -> 3.*: what's the upgrade path? What are the breaking changes? HOT 1
- Problem upgrading Buddy-sign from 0.3.0 to 2.2.0 HOT 1
- JWS unsigned alg should be read out of the JOSE header if available HOT 3
- Errors in using :eddsa algo for claims signing HOT 1
- [PERFORMANCE] - avoid reflective calls HOT 6
- buddy.sign.jwt/unsign fails when hs256 is not used and alg is unspecified HOT 4
- Buddy JWT doesn't support the NONE algorithm HOT 1
- Tag and Changelog Version 3.4.351 Wrong HOT 1
- Call resolve-key in sign function on pkey HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from buddy-sign.