Hi Omri, I have worked extensively on implementations where Keycloak externalizes authorization decisions to an external PDP, specifically Open Policy Agent (OPA), so I found your proposal particularly interesting.
For reference, below is an example of integration between Keycloak and OPA that illustrates how token issuance decisions can be delegated to an external policy engine: https://github.com/tefiros/keycloak-opa-authz-demo/tree/main I am also including an example Rego policy: https://github.com/tefiros/Access-control-helm/blob/develop/test/kck.rego This policy illustrates how issuance decisions can be enforced externally. For example, it can deny token issuance when specific conditions are not met, such as requiring the use of OpenID Connect before a token can be returned. We have also documented this approach in research projects where Keycloak interacts with an external PDP: * * https://robust-6g.eu/wp-content/uploads/2026/05/ROBUST-6G-D2.3_v1.0.pdf (Section 5.1.2.4) * https://www.sns-itrust6g.com/wp-content/uploads/2026/05/iTrust6G-D4.2.pdf (Section 4.1.2) * These references may be useful as implementation experience for the discussion around externalizing token issuance decisions and the practical integration of OAuth/OIDC infrastructures with external policy engines. If this is of interest, I would be happy to discuss it in more detail. It could be an interesting topic to continue exploring in future IETF meetings and discussions, or perhaps through collaborations as well. Best regards, Lucía De: Omri Gazitt <[email protected]> Fecha: miércoles, 5 de agosto de 2026 a las 8:40 Para: [email protected] <[email protected]> Asunto: [OAUTH-WG] For review/discussion: externalizing the token issuance decision to a policy decision point AVISO/WARNING: Este correo electrónico se originó desde fuera de la organización. No haga clic en enlaces ni abra archivos adjuntos a menos que reconozca al remitente y sepa que el contenido es seguro / This email has been originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi folks, Yaron Sheffer's thread<https://mailarchive.ietf.org/arch/msg/oauth/CCvvii3fjQWYczpYgzVC2Aoa9-U/> in June/July on standardizing a policy language framed the question as one about scope: whether authorization policy, kept out of OAuth's scope for years, is due for a revisit. That thread took up policy on the OAuth wire. I have submitted two drafts about the other half of it, policy behind the wire, which I don't think has been discussed here much if at all. It also sidesteps the hardest part of Yaron's question. Agreeing on how an authorization server poses the question does not require agreeing on the language the policy is written in, and OpenID AuthZEN 1.0 already defines how to structure the question. [In full disclosure, I am a former co-chair of the OpenID AuthZEN working group and an editor of the Authorization API.] The observation the drafts start from is that a long list of OAuth specifications define a moment at which an authorization server decides whether to issue a token, and every one of them declines to define the decision. Transaction Tokens is the bluntest about it: "the authorization policy for determining such issuance is out of scope for this specification." RFC 8693 and Identity Chaining each do the same thing in a subordinate clause. ID-JAG gets closest, and describes an interface in prose: the AS "evaluates administrator-defined policy [...] and determines if the client should be granted access to act on behalf of the subject for the target audience, resources, scopes, and authorization details," and adds that granted scopes may be a subset of those requested. Each of those is the right editorial call for the document it appears in. My observation is only that the same call made four times leaves the most security-relevant step in issuance with no interoperable expression, and that the industry has needed to fill this gap: five major authorization servers ship a proprietary extension point at exactly this moment, and only one of the five can refuse to issue. The drafts profile the OpenID AuthZEN Authorization API for that moment, casting the AS as a policy enforcement point: * AuthZEN Profile for OAuth 2.0 Token Issuance<https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-issuance/> - the mapping from a token request onto AuthZEN's five-tuple, and the rules by which a decision may shape the issued token. §4 covers the deployment question of whether an authorization server can afford a policy call at issuance rates. * AuthZEN Binding for OAuth 2.0 Token Exchange<https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-token-exchange/> - the binding for RFC 8693 and the family that inherits its seam: identity chaining, ID-JAG and transaction tokens, where a request names a second party whose authority is separately at stake. Nothing here changes anything on the OAuth wire. A client cannot tell whether the AS consulted a policy decision point, and no new parameter, endpoint or error code is defined. That is deliberate, and it is also the crux of question 1 below. Open questions. These are also filed as issues here<https://github.com/ogazitt/oauth-authzen/issues> if a reply is easier there than on the list, though I would rather have it here. 1. Is this in scope for OAuth at all? Because the profile is invisible on the wire, there is a real argument that it belongs at the OpenID Foundation as an AuthZEN profile, and I have had that feedback directly. The counter is that the sentences being filled in are in this working group's documents, and its participants are the ones who wrote them. Question 2 is the sharpest version of this: whatever the answer is, it is not one the OpenID Foundation can give. I would rather ask than assume. 2. What should an AS return when policy refuses? I could not find a consistent answer, and I would like to be told I missed one. RFC 8693 section 2.2.2 says `invalid_request` where the presented tokens are unacceptable on policy grounds. Identity Chaining points at RFC 7523 section 3.1, whose own MUST is about JWT validity rather than policy, and which lands on `invalid_grant`. ID-JAG and Transaction Tokens describe the permit branch and leave the deny branch unwritten. If the answer is that `invalid_grant` is the understood catch-all and the coarseness is deliberate, that is a fine answer, and I would rather write it down than have a profile invent something. 3. Is a new IANA registry the right way to name the gate action? It is currently `issue:<token-type>:<grant-type>` built from registered short names, in a new registry, rather than from the existing grant type URIs. The reason is that policy engines have real length and character constraints on relation identifiers, but I am not confident this is the right trade and it is the kind of naming call this working group is better at than I am. 4. Is "may narrow, never broaden" the right invariant for the response? (section 6.3 of the issuance draft, and the rule I would most like challenged.) A decision may shorten a lifetime, drop scopes or tighten an audience, and may never add authority. Everything else in the response handling falls out of it, including which fields an implementation may ignore. If there is a legitimate case for a policy decision point adding authority at issuance, the design is wrong and I would like to hear it now. There is a longer write-up<https://notes.ogazitt.com> of the argument, including the survey behind the five-vendor claim above. Next steps include implementing the drafts with a Keycloak module rather than leave them on paper, and would take that work in whichever direction the answer to question 1 points. Thanks! Omri. -- Omri Gazitt ---------- Forwarded message --------- From: <[email protected]<mailto:[email protected]>> Date: Tue, Aug 4, 2026 at 11:05 PM Subject: New Version Notification for draft-gazitt-oauth-authzen-issuance-00.txt To: Omri Gazitt <[email protected]<mailto:[email protected]>> A new version of Internet-Draft draft-gazitt-oauth-authzen-issuance-00.txt has been successfully submitted by Omri Gazitt and posted to the IETF repository. Name: draft-gazitt-oauth-authzen-issuance Revision: 00 Title: AuthZEN Profile for OAuth 2.0 Token Issuance Date: 2026-08-05 Group: Individual Submission Pages: 36 URL: https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-issuance-00.txt Status: https://datatracker.ietf.org/doc/draft-gazitt-oauth-authzen-issuance/ HTML: https://www.ietf.org/archive/id/draft-gazitt-oauth-authzen-issuance-00.html HTMLized: https://datatracker.ietf.org/doc/html/draft-gazitt-oauth-authzen-issuance Abstract: Numerous OAuth 2.0 specifications define a moment at which an authorization server decides whether to issue a security token, and each of them declares the decision itself to be a matter of local policy that is out of scope. The result is that a decision common to every OAuth deployment has no interoperable expression. This document defines a profile for using the OpenID AuthZEN Authorization API to externalize that decision to a Policy Decision Point. It specifies how the inputs to a token issuance request map onto AuthZEN's mandatory five-tuple, how a Policy Decision Point response may shape the issued token, and how the two parties discover each other's capabilities. The mapping is complete for grants whose request names a single party and a single target, including the authorization code and client credentials grants. Companion documents bind the grant families that add structure this document does not model, the token exchange family first among them. The IETF Secretariat ________________________________ Este mensaje y sus adjuntos se dirigen exclusivamente a su destinatario, puede contener información privilegiada o confidencial y es para uso exclusivo de la persona o entidad de destino. Si no es usted. el destinatario indicado, queda notificado de que la lectura, utilización, divulgación y/o copia sin autorización puede estar prohibida en virtud de la legislación vigente. Si ha recibido este mensaje por error, le rogamos que nos lo comunique inmediatamente por esta misma vía y proceda a su destrucción. The information contained in this transmission is confidential and privileged information intended only for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this transmission in error, do not read it. Please immediately reply to the sender that you have received this communication in error and then delete it. Esta mensagem e seus anexos se dirigem exclusivamente ao seu destinatário, pode conter informação privilegiada ou confidencial e é para uso exclusivo da pessoa ou entidade de destino. Se não é vossa senhoria o destinatário indicado, fica notificado de que a leitura, utilização, divulgação e/ou cópia sem autorização pode estar proibida em virtude da legislação vigente. Se recebeu esta mensagem por erro, rogamos-lhe que nos o comunique imediatamente por esta mesma via e proceda a sua destruição
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
