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.