[keycloak-user] OpenID Connect support

[Raghuram]

Hi Bill -  here is my understanding  of the spec:

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

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. 

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.

Section 3 (openID provider metadata) of the discovery spec mentions that issuer is a url using https.

Hope I make sense.

Thanks.
Sent from my iPhone

> On Oct 30, 2014, at 4:58 PM, Bill Burke <bburke at redhat.com> wrote:
> 
> Ivan, btw, looking at the library you are using, validation of the ID token is optional.
> 
>> On 10/30/2014 4:15 PM, Raghuram wrote:
>> 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.
> "aud" has been fixed in master.
> 
> "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.
> 
> "AZP
> 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.
> 
> 
>> Used /account for userinfo end point that didn't work. Will provide more feedback as I continue to test
> 
> 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.
> 
>> Fyi -My libraries were tested completely against a server implementation based on Mitre's open Id connect and they are good.
> 
> 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.
> 
> 
> -- 
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com