CODEWITHSUNDEEP
oauth-2.0single-sign-onopenid-connectaccess-tokenrefresh-token
kaounKaoun
kaounKaoun

Reputation: 661

Openid connect/ Oauth2 for Rest APIs

I have different web applications which are registered on IDM (vmware IDM https://github.com/vmware/idm/wiki/Integrating-Webapp-with-OAuth2#authentication-response)

As obvious, all applications are registered with there own client id and client secret. When a user tries to access webapp "A" (webappa.com), it redirects to my IDM login page and after authentication comes back with code that can be exchanged with access and refresh token. Similar thing happens with webapp "B" etc. This works well. Now I am confused with following 2 use cases?

a. I want to use some API (webappa.com/api/v1/get_user_projects) from webapp "A" for some scripting purpose. So my question is how I can authenticate these APIs against the user? Can I get the tokens for the user from IDM provider by passing his credentials (using some APIs?). If answer to it is NO, then how usually it is handled?

b. Can webapp A and webaap B will have same access/ refresh token at a time against a user?

Upvotes: 0

Views: 124

Answers (1)

Gary Archer
Gary Archer

Reputation: 29208

a. When a user authenticates it is with certain permissions and for a certain period of time. OAuth is designed so that you can just forward tokens between microservices - but you cannot elevate the permissions or time for a user token. Depending on your use case you may want to consider a different token with different privileges for background tasks.

b. It is possible but not advisable to follow the Google model via a cookie scoped to a web domain that hosts multiple apps, which is how Google do it (mail.google.com / drive.google.com). So there is a dependency on hosting and domains

The preferred option is for the user to authenticate at App A and then single sign on to App B. The different apps then get separate tokens with different permissions and can more easily evolve separately.

This also depends on how the app is implemented and your technology choices:

  • An 'old style' web app using a server side technology will expect to issue separate auth cookies per app

  • An SPA following an intelligent Back End for Front End design could support this model via SameSite cookies if it made sense for a set of related micro-UIs

In the latter case you would need to use a single OAuth client with multiple redirect URIs - eg for mail and drive - since the user could sign in to either of these first.

Apologies for the complicated answer - but it is a very architectural topic with the potential for hidden costs. From a stakeholder viewpoint it is very simple - make it work like Google. Hopefully this answer helps you in your conversations ...

Upvotes: 2

Related Questions