Comments (7)
An alternative implementation using the claims
request defined by OpenID Connect has been implemented in version 1.2.0 .
This should take care of the above use cases. If the need for further extensions arises, feel free to open a new issue.
Closing.
from omejdn-server.
Note that for the purposes of the OP, the claims
request parameter is not useful.
The issue being that the client credentials authorization flow with JWTs does not need an authorization request and thus has no way of providing the parameter.
Also, this requires the use of OIDC (scope includes openid
) which also does not apply in the use case.
from omejdn-server.
Correct, which is why we deviate from the OIDC core spec as follows:
- The
claims
parameter can be used at both the/authorize
and/token
endpoints. - Besides
id_token
anduserinfo
(the latter not yet implemented), the request parameter has an additionalaccess_token
claims sink, allowing to request claim values within the access token. This makes usage without OIDC possible.
This behaviour is documented in this expired RFC draft, which our README links to. The configuration options are described in our Wiki.
A comparison to the proposed changes by @milux :
- The current approach relies mostly on existing code due to its similarities to standardized OIDC behaviour, which means less maintenance for different methods achieving essentially the same goal.
- The current approach is already well documented, even if in an expired draft.
- @milux `s approach had the added benefit of protecting the integrity of the requested values due to their inclusion in the JWT Bearer. This would have allowed to relay the Authentication requests via third parties. After talking to @milux it became clear this was not a concern for the use case.
- The above draft also defines claims sinks like
*
, meaning "to be included in all applicable claims sinks", which can be quite useful.
from omejdn-server.
@schanzen Are there any plans for an alternative, more standards based solution (even if just emerging) or can we close this issue again for the time being?
from omejdn-server.
We should do this using the client assertion (JWT). Using a query parameter is specifically violating the standard:
The
authorization server MUST ignore
unrecognized request parameters. Request and response parameters
MUST NOT be included more than once.
from omejdn-server.
This requirement seems more like a statement to allow for backwards compatibility of future revisions, in that additional parameters introduced in such revisions should not break older Auth Servers which do not recognize them.
In other words: unrecognized request parameters
would refer to parameters unknown to the server, not the spec.
A bit off-topic, but the second sentence might pose a problem in other ways, as it is repeated for both the Authorization- and Token endpoints. RFC 8707 however states:
Multiple "resource" parameters MAY be
used to indicate that the requested token is intended to be used
at multiple resources.
from omejdn-server.
Ok. Well. LGTM in general. We can always change it to a property in the JWT if necessary later.
from omejdn-server.
Related Issues (20)
- Separate User selection from authentication HOT 3
- Simpler Certificate File Names HOT 1
- Certificate Bound Access Tokens HOT 4
- Misleading documentation HOT 1
- Outputs are cached instead of written to stdout on Docker HOT 1
- Client Certificate Revocation Checks
- Warn or refuse to import invalid certificates HOT 2
- How to request an access token? HOT 4
- Respect `response_mode` in error responses
- Sanitize scopes in Session
- Show requested Claims to User
- Rethink Logouts HOT 1
- DAPS capability of holding one attribute HOT 5
- Logout URL formatting issue
- Bug in KEYS_LOAD_ALL event of DefaultKeysDB HOT 1
- Invalid request: Content longer than specified HOT 4
- Make `scope` optional in token request for `client_credentials` HOT 1
- Features and Specification HOT 2
- JWKS endpoint as a high risk resource of the entire dataspace HOT 1
- The ```resource_owner.attributes``` field used by ```filter_scopes``` is not a ```Hash```
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 omejdn-server.