Using OpenID Connect for First Party SSO

Questions
1

Hey All

I’ve been digging deep into how we are going to be structuring our SSO solution for the company I work at. The issue I am facing is one that allot of people face. Which is that the docs and info out there in reguards to OAuth/OpenId Connect are somthing like so: Website X wants to access info/update info for it’s users accounts on another platform (Website Z) that Website X so instead of Website X getting the user to hand over UserName/Password for Website Z, they get an access token that allows them to push data to the third party API on behalf of the user.

However what I want is to provide a SSO service to my first party apps which all maintain user priviliges internally. So why would it be bad practice to use OAuth’s auth token to authorize access to an API endpoint and restrict what values they can change based upon data inside of a JWT which contains that users email (which we internally can tell if they are allowed to make those changes).

I understand that if you provided external parties access to your API then you would have issues, but we only ever plan on using the Oauth/OpenId Connect server to add SSO to our many apps. Is the primary issue just that the spec doesnt support a standard way to ensure that they token is only used for the client it was issued to (the aud claim)?

So if thats the case and the issue is purely that there isnt a standard way to lock down that the token is only used to prove who sombody is then why cant I just use OpenId Connect?

Everywhere I read states that id_tokens should only be used for personalizing the client AND NOT for authorizing. Is this rule purely because of the initial use case I described above where two companies who cannot trust each other? What about if my web app + the api + the auth server I control exclusively? Is it then just purely bad practice??

If I want to implement everything as you are supposed to I would need to submit both the id_token and access_token to that the auth server replies to my react app with to my API server. The access_token to prove that I am allowed to access the API resource and the id_token to prove that the user behind this token has been authorized by the access_token can only do stuff which the API’s business rules allow for.

Or perhapse the answer is that the user gets ONLY the id_token from the Auth server, sends that id_token to the API server, of which that server responds with an access_token unique to that API server. This feels like the answer, but then I get the issue in which I now need to implement refresh tokens if I want short lived tokens via refresh.

Cheers

2

It’s a little bit too much :slight_smile: I’m not sure I’m following you in regards what you problem is. Can you maybe try to put a list of questions?

If you want to do SSO with your apps, it’s totally fine to use OIDC, where your app would be sent an id_token, so that the application would check it’s DB and decide, what is allowed for this user.

3

Hi Philipp

Looking at all the information avaliable this does feel like the correct solution, however there are conflicting information sources saying that the OpenId Connect IDToken should not be used as a way to gain access to an API. Perhaps this is more of a rule for when you have third parties integrating with your API.

I really believe the correct solution is to have the SSO service + web api with its own access token provider. The issue there is that all this work that goes into creating short lived tokens feels like an overhead that I would much prefer to avoid when providers like okta + any other OpenId Connect services have already done all that hard work. plus the flow would be pretty janky I feel.

I think the dumb/easy solution could just be use the access token as a blanket access into the system and the id_token perhapse is passed in along side the access token as away to attribute actions in our logs/fine grained access controls. It just doesnt feel correct.

4

Yes, it’s considered to be a best practice to not use id_token for granting access and vice versa. But in your case if you can guarantee that:

  • the aud of id_token is a known party (whitelisted and trusted)
  • you validate the JWT signature
  • the signature algorithm uses asymmetric encryption of a payload digest (RS256) so that you know, the JWT payload was not altered and re-signed by a client
    then you know, that a user is who authenticated himself to the authorization server. And after that you can look up grants given to it in your application db.

But then again, maybe all of that doesn’t make any sense and not even relevant in you case, as I don’t quite understand the problem you are facing. How is your application different from million other ones on the web, which do SSO with services like Google, Facebook and other social IdP?