2

We have several websites where users have to log in. For each website we want to support a single signon solution based on JWTs (JSON Web token).
There are also several (other) websites that can act as Identity Provider.

When the user accesses our website and is not authenticated, he can choose which identity provider he wants to use. The identity provider sends a JWT claim which in its simplest form says 

 { "username": "john.doe" }

This is (hmac) signed with a shared secret so our website can check the authenticity of the claim.

In my situation a website can support multiple identity providers and an identity provider can work for multiple websites. All combinations have unique shared secrets.

My question is about how an identity provider can know which shared secret to use as it supports multiple websites. Would it make sense to request the identity with https://idp1.example.com?aud=mywebsite.com where mywebsite.com is the website asking for identification.

The other way around I have a similar problem: when mywebsite.com receives a JWT how can it know which secret to use for verification. Would it make sense to ask the identity provider to include "iss": "idp1.example.com" which can be used by mywebsite.com to find the secret to use?

|improve this question
  • Is this more appropriate on Stack? Seems like a programmatic/logic problem rather than a security one. – HashHazard Aug 30 '16 at 21:37
2

All of these details have been worked out in OpenID Connect. I would strongly suggest implementing that (or using an existing implementation) rather than inventing your own protocol.

|improve this answer
  • Indeed. The OpenID Connect authentication request has a client_id field that indicates the website asking for authentication. This client must be already known at the identity provider, and it has a key configured to use as a shared secret. – Sjoerd Aug 31 '16 at 7:05
  • In the future I would certainly like to implement OpenID or something similar but right now there is not enough time/money to do that. But to be future proof I try to use as much the appropriate claim-names. The client_id and audience seem to serve a similar purpose. – Jeff Aug 31 '16 at 11:15
  • 1
    There are lots of attacks against authentication protocols. If you must roll your own then I really wouldn't rush it. Use something off the shelf if you can. – Neil Madden Aug 31 '16 at 17:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.