<html><body><div style="color:#000; background-color:#fff; font-family:HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif;font-size:16px"><div id="yui_3_16_0_1_1414758143432_3154" dir="ltr"><span id="yui_3_16_0_1_1414758143432_3657">Read the spec once again and agree to your point that access code can only be used once. Regarding "iss", as long as realm name is replaced by URL, it should be good. </span>I will do some more testing today, mostly on validating the signature of the token and will let you know if I find any discrepancies.</div><div id="yui_3_16_0_1_1414758143432_3154" dir="ltr"><span><br></span></div><div id="yui_3_16_0_1_1414758143432_3154" dir="ltr"><span id="yui_3_16_0_1_1414758143432_5128">Thanks once again, for the response and explanation.</span></div> <div class="qtdSeparateBR"><br><br></div><div class="yahoo_quoted" style="display: block;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div style="font-family: HelveticaNeue, Helvetica Neue, Helvetica, Arial, Lucida Grande, sans-serif; font-size: 16px;"> <div dir="ltr"> <font size="2" face="Arial"> On Thursday, October 30, 2014 8:53 PM, Bill Burke <bburke@redhat.com> wrote:<br> </font> </div> <br><br> <div class="y_msg_container">Section 3 does mention that the issuer is a URL using HTTPS, but this <br clear="none">URL does not have to match the token endpoint URL. It is just a unique <br clear="none">identifier for the issuer. That's it.<br clear="none"><br clear="none">Maybe I'm just not understanding OIDC, but what you are describing for <br clear="none">"aud" and "azp" doesn't make sense to me. An ID Token is not an access <br clear="none">token. Its not something you pass around to use for authz. Neither do <br clear="none">you pass around access codes. Access codes are only usable once.<br clear="none"><br clear="none">Keycloak just doesn't support multiple audiences. When an oauth client <br clear="none">is registered, a set of valid redirect uri patterns are associated with <br clear="none">it. You cannot associate a client with another client. The ID Token <br clear="none">will only ever contain one client_id in the "aud" and the "azp" will <br clear="none">always be blank because its an optional setting.<br clear="none"><br clear="none">We support narrowed "trust" by role scope mappings. When an access <br clear="none">token is created for a specific client, it is only granted permissions <br clear="none">that are configured for that client's scope. For example:<br clear="none"><br clear="none">* Service 'A' has roles of "user" and "admin"<br clear="none">* Service 'B' has roles of "admin" and "analyst"<br clear="none">* User has a role mapping of A.user, A.admin, B.admin, B.analyst<br clear="none">* Oauth client "C" is registered with a role scope mapping of A.user<br clear="none">* Oauth client 'C' initiates a token request on behalf of the User, it <br clear="none">gets an access token only with a permission of 'A.user' even though the <br clear="none">user has other permissions. So it wouldn't be able to access Service 'B' <br clear="none">at all.<br clear="none"><br clear="none"><br clear="none"><br clear="none">On 10/30/2014 6:42 PM, Raghuram wrote:<br clear="none">> Hi Bill - here is my understanding of the spec:<br clear="none">><br clear="none">> Section 3.1.3.7 of the core spec says that clients must validate the id tokens. The third point of the same section says that "aud" can contain more than 1 element in which case the fourth point says that the client should verify that "azp" is present and the fifth point says azp should be verified against the client id<br clear="none">><br clear="none">> Now when an oauth client registers, it can specify multiple redirect Uris, corresponding to diff oauth clients that wish to participate in a single sign on. When a user tries to access first client and he is authenticated, the client just gets a code. If the code is passed to the second client ( the first client could be web app and the second client could be a database service) then the second client could get an Idtoken. The auth server (key cloak in this case) would then list all the client ids in "aud" and specify the second client in "azp" which will be validated by the second client.<br clear="none">><br clear="none">> The above is a valid use case in our organization ( authentication delegation). It gives flexibility to the apps ( especially sensitive ones) to pick the apps they trust rather than just participate in an organization wide single sign on.<br clear="none">><br clear="none">> Section 3 (openID provider metadata) of the discovery spec mentions that issuer is a url using https.<br clear="none">><br clear="none">> Hope I make sense.<br clear="none">><br clear="none">> Thanks.<br clear="none">> Sent from my iPhone<br clear="none">><br clear="none">>> On Oct 30, 2014, at 4:58 PM, Bill Burke <<a shape="rect" ymailto="mailto:bburke@redhat.com" href="mailto:bburke@redhat.com">bburke@redhat.com</a>> wrote:<br clear="none">>><br clear="none">>> Ivan, btw, looking at the library you are using, validation of the ID token is optional.<br clear="none">>><br clear="none">>>> On 10/30/2014 4:15 PM, Raghuram wrote:<br clear="none">>>> I tested with libraries based on Apache Oltu and even I noticed that realm name is being sent in the Idtoken under "iss". "aud" is null when I included multiple redirect Uris which is breaking the validation (as per openid spec). "azp" is not being sent (it is optional unless more than 1 client is registered) - expect that to be sent once I register two clients.<br clear="none">>> "aud" has been fixed in master.<br clear="none">>><br clear="none">>> "iss" still is the realm name. This is just a unique identifier for the realm. And there is nothing in the spec that I could find that states that it must match the token endpoint URL. It just has to be a URL that uniquely identifies the issuer. It is something that is configured, or, found during OIDC discovery.<br clear="none">>><br clear="none">>> "AZP<br clear="none">>> Your interpretation of AZP is not my interpretation of AZP. #1. AZP is optional, we don't have to include it at all. #2 It would only have the value of the client that requested the token. In Keycloak, ID Tokens are generated and only given to one audience.<br clear="none">>><br clear="none">>><br clear="none">>>> Used /account for userinfo end point that didn't work. Will provide more feedback as I continue to test<br clear="none">>><br clear="none">>> As I said before, we do not support userinfo yet. Our access tokens are Json Web Signatures signed by the realm and the content is an extended version of ID Tokens that contains additional keycloak metadata.<br clear="none">>><br clear="none">>>> Fyi -My libraries were tested completely against a server implementation based on Mitre's open Id connect and they are good.<br clear="none">>><br clear="none">>> It's on the roadmap to expand our OIDC support beyond the minimal requirements and to validate it against other implementations. Just haven't gotten to it yet.<br clear="none">>><br clear="none">>><br clear="none">>> --<br clear="none">>> Bill Burke<br clear="none">>> JBoss, a division of Red Hat<br clear="none">>> <a shape="rect" href="http://bill.burkecentral.com/" target="_blank">http://bill.burkecentral.com</a><div class="yqt2280791068" id="yqtfd85961"><br clear="none"><br clear="none">-- <br clear="none">Bill Burke<br clear="none">JBoss, a division of Red Hat<br clear="none"><a shape="rect" href="http://bill.burkecentral.com/" target="_blank">http://bill.burkecentral.com</a><br clear="none"></div><br><br></div> </div> </div> </div> </div></body></html>