The situation is thus: I have one application (let's call it the manager app because I'm really not sure how to assign the Resource and Client in this situation) that will be accessing data from an unspecified number (between 0 and infinity) of other applications (I'll call these the provider apps). The manager app will be using OAuth2.0 to authorize with the provider apps so that it can securely gather the needed data.
All of the apps (both my manager app and all of the provider apps) have been registered as "clients" (I'm not sure I'm using the term correctly here) with our in-house OAuth2.0 Authorization Server. Each of these clients has been assigned scopes for which they are permitted to access other applications.
The primary question is:
"Do I need to register a unique OAuth2.0 Client for the manager app to preform it's authorization with each of the manager apps, or do I use a single OAuth2.0 Client for the manager app that works for authorizing with every provider app based solely on the scopes assigned to it?"
Furthermore, for at least one of the provider apps, more information than just the scopes is needed for proper Authorization (essentially this information allows me to identify which tenant the Authorization is attempting to communicate with). In the past, I used HTTP headers to pass this information, however the manager application is not capable of adding headers to the data requests, nor does it have a concept of the exact information I need. Fortunately, the manager application does have access to a pair of values that can be combined to determine the critical information, however it still cannot add these values to the HTTP headers.
Question 2 is:
"I'm expecting to use claims in the JWT to provide the necessary information, but is this the correct method, and if it is, does this change whether I need unique manager app clients for each provider app?"
You will need to at least have separate logic for each. I would suggest using two separate clients to keep it clean, but it's not necessary as long as you're handling, in your app, the right calls and claims analysis to the proper places. This can easily get confusing and hard to debug.
Related
Please forgive my ignorance on this topic. I've been a developer for a long time, but there's a huge gap in my knowledge and experience when it comes to authentication & authorization protocols and proper handling of tokens.
We've got a whole homegrown suite that consists of:
4 web apps (2 in Ruby/Rails, 1 in Elixir/Phoenix, 1 single-page React)
1 image server (serverless app written as an AWS Lambda / API Gateway)
1 custom data API (also serverless Lambda / API Gateway)
We also have an Amazon Cognito User Pool connected to our backend identity provider to authenticate users and generate tokens.
All but one of these allow some form of anonymous access; the other is only available to logged in users. If a user is logged in, they all need to access the user's profile info from the ID token, preferably without initiating another auth flow. Our backend apps may also need to make use of the access token, but obviously we wouldn't be handing that out to to the SPA or public API consumers.
My first thought is to store the tokens in a key/value store on the backend, and have a short-lived, encrypted JWT containing a unique session ID set on the shared domain that all of the backend apps have access to, with the key stored in a config secret. By decoding the session ID, they can get what they need from the data store. The API would also refresh when necessary.
I also know that API Gateway can use a Cognito user pool as an authorizer, but I'm unclear how I would make that work while integrating it with the rest of our apps and requirements above. Sometimes requests to the API are made from the browser (in the React app, for example), and sometimes they come from the backend of one of the web apps.
The image server and API are used by our apps, but are also documented and accessible for other people to build their own applications on. But they would have to register their apps as OIDC clients to receive any profile info from logged in users.
I'd love some advice on how to make all of this work, or at least pointers toward resources that might help make it less dizzying.
I can't help but think I've implemented Open ID slightly incorrectly, but I also cannot find why I've done the implementation the way I have is bad or not.
Scenario:
Website - Used forms authentication before being updated to use OWIN. Forms auth has been stripped out.
Website now supports OpenId to Okta. This is being implemented for a large company of our users to facilitate their logins. This is functional.
The method I use for the site models how Microsoft does logins. On email domain detection, we redirect the user to the login page for their domain. In this case, Okta. We receive the callback, and look up the user in our existing data, and generate a cookie based on our existing data (or create a new user account if they don't have one).
Essentially, just using Okta to confirm they are a valid user, and then we log them in with our user data. We foresee doing this for other companies as well.
Problem:
I have a desktop (WPF) client that requires a login to our website. This talks to API's that already exist using an auth key/token system we built many years ago. Ideally, we do something similar. Use Okta to verify the user is a user of that system, then generate a token that can be used for these API's.
Here is where I'm not sure I've done this appropriately.
The desktop client calls an API endpoint on our site with the email domain the user entered. We verify the user's domain is allowed to use SSO, and if so, we issue back a challenge endpoint for the client to call. This challenge endpoint is then called by the desktop client to launch the users default browser.
This challenge endpoint is an endpoint on OUR website, that essentially triggers the challenge to the IdP. After login, a callback is called on OUR website, to process the auth response. We verify the user's account is valid, and get the refresh token from the response. With the refresh token, and an identifier of the user, this data is then sent back to the desktop client using localhost:randomPort so the client can consume the refresh token and identitifer. (Note that I do encrypt the refresh token and identifier's before returning them to the client)
This refresh token is then POSTed to OUR website, along with their identifier (so we can identify the IdP we should call), then use an OIDC client to verify the refresh token is still valid. If the refresh token is still valid, we generate an app token and return it.
Is there a glaring issue with how this is implemented that I'm not seeing? How can I do this differently?
You seem to be missing the role of an Authorization Server (AS) that you own, to manage connections to other systems and to issue tokens to your apps.
You seem to have some good separation and to be doing quite a few things well - eg you are using your own tokens rather than foreign Okta tokens. The main issue is likely to be growing the system.
PREFERRED BEHAVIOUR
An AS should result in simpler code and a system that is easier to extend:
You can add new authentication methods quickly
This should involve just adding a connection (eg Okta) to your AS
Doing so requires zero code changes in your UIs and APIs
Your UIs just use standard OpenID Connect flows and call AS endpoints, regardless of the authentication method used
Your APIs just verify tokens issued by the AS, then authorize requests, regardless of the authentication method used
Some scripting is needed in the AS, but typically this is small.
FEATURES
In terms of what an AS should do for you, have a browse of the Curity Concepts Pages. I work there, and we try to write about the science of OAuth and the common extensibility features software companies need.
CHOOSING YOUR MOMENTS
Integrating an AS and getting past all the blocking issues is a gradual journey though, and involves learning. So it requires choosing your moments, spikes and getting buy in from your stakeholders.
The main objective should always be simple and standard code in your apps, that is easy to scale. OAuth and the Authorization Server give you design patterns that help with this.
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?
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 ...
I have an old windows application written in VB.NET with SQL server backend. Currently the new user additions, deletion, adding entitlements etc. are managed by an old approval workflow system. After getting approvals, the user details and entitlements are inserted in to the SQL server database table manually.
I am trying to integrate this application with the SailPoint's Identity and access management. So the new user addition, deletion update and adding entitlements etc will be done through Sailpoint. For this, I would require to create a WEB API which can be called by Sailpoint and expose the functionalities(add user/delete user/add entitlements). The only consumer to this API is SailPoint.
I am new to OAuth and below are the grant types that I came across. But not sure which one I should be using in this particular scenario.
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
I have done research on the different authentication methods that we can use to secure the web api. But still confused on which one to apply in this scenario as this new web api is going to be made available in internet.
I already tried developing a POC with the OAuth 2.0 with password grant type referring this article. But when I read articles in the internet I found that the password grant type is not that secure and is deprecated.
Could you please advise on which grant type(client credentials/authorization code/implicit) to use in this scenario. I believe authorization code is used when the user is directly trying to access the API. In this scenario, SailPoint will be calling the API in the backend programmatically when they insert a new user in their UI.
I think it's a good approach to use client credentials in this case because the communication between IIQ and your Web API can be considered an API-to-API communication, I mean, IIQ is acting on behalf of itself in this communication.
See this article for more details - https://dzone.com/articles/four-most-used-rest-api-authentication-methods (bold part by myself)
OAuth 2.0 provides several popular flows suitable for different types
of API clients:
Authorization code — The most common flow, it is mostly used for
server-side and mobile web applications. This flow is similar to how
users sign up into a web application using their Facebook or Google
account.
Implicit — This flow requires the client to retrieve an
access token directly. It is useful in cases when the user’s
credentials cannot be stored in the client code because they can be
easily accessed by the third party. It is suitable for web, desktop,
and mobile applications that do not include any server component.
Resource owner password — Requires logging in with a username and
password. In that case, the credentials will be a part of the request.
This flow is suitable only for trusted clients (for example, official
applications released by the API provider).
Client Credentials —
Intended for the server-to-server authentication, this flow describes
an approach when the client application acts on its own behalf rather
than on behalf of any individual user. In most scenarios, this flow
provides the means to allow users to specify their credentials in the
client application, so it can access the resources under the client’s
control.
I am accessing Google APIs from a native iOS app (using gtm-oauth2) and from my web app, which each have different client ids.
When I try to refresh the access tokens with refresh tokens created by a different client id of the one it was initially generated with, I get an authorization error.
I don't want users to be required to allow access to my app more than once.
Is it possible to make both client ids work interchangeably?
Or is there a way to use the web's client id on the iOS platform (with gtm-oauth2 or without)?
I think you need to understand a little about how Oauth2 works.
When a user grates you access to there data they are granting it to your Application. In order to do that Oauth2 needs to know what application is requesting access. The application is identified to Oauth2 by its client id. The Access token Refresh token is made for the specific application.
By having two different client ids you have two different applications and the refresh tokens cant be interchanged
I haven't tried this but it might work. Have you tried using the client id from your web app in the IOS app? If it does / or doesn't work I would love to know for future reference.
I hope this helps.