We are planning to use OpenID Connect / OAuth2 to handle access to a list of resource servers.
We want to use JWT as access token when a user is going to call one of the resource servers. The access token will be issued by an auth server in our landscape according to OpenId Connect / OAuth2 standards. Access will be granted or rejected to the calling user based on the JWT access token.
The standards are new for us so we are still reading and understanding.
We are currently searching for an option to do a lookup of the resource servers with a call to auth server. We would like to use it in order to simplify the clients.
Is there any option available in OpenId Connect / OAuth2 to help clients finding the available resource server? Is there any endpoint available in auth server to do that? Or can the answer with the JWT be enhanced to return the list of the resource servers?
Thanks in advance
Thorsten
With the use of JWT, there is no need to go for one extra validation from the authorization server. Token & its claims should be enough to validate the access rights. You can customized the token claims as per the needs.
An Authorization Server does not know the list of APIs, since APIs are not usually registered as clients. There are some related concepts though. The IAM Primer article has a good overview on how these concepts fit together.
Each API covers an area of data and this maps neatly to the OAuth Scopes included in access tokens.
Each API has an audience, such as api.mycompany.com, which maps to the aud claim in an access token. This can enable related APIs to forward the same access token to each other and securely maintain the original caller's identity.
An API gateway is usually hosted in front of APIs, as a hosting best practice. This enables clients to use a single, easy to manage, API base URL, such as https://api.mycompany.com, followed by a logical path.
Related
I have API which is hosted in Azure. It is using Microsoft Identity platform for Authorization. Now we need to integrate APIM Gateway for the API. APIM also provides OAuth Authorization. So my question is should I configure OAuth for my API in APIM since Api would be deployed in APIM or I can continue to use Microsoft Identity platform which is doing its job. So I am looking for benefits for using OAuth from APIM rather than throw Microsoft Identity. In other words what would be difference and pros using OAuth vs Microsoft identity which also relies on OAuth?
Each API should validate a JWT access token on every request, then use the token's scopes and claims to authorize access to resources. This is sometimes called a zero trust architecture.
Another important requirement is to avoid revealing sensitive data in tokens, such as emails, to internet clients. The phantom token pattern has more info on this, and involves the use of an API gateway.
I would favour a solution where there is an API gateway in front of your APIs. This is a hosting best practice and also enables you to perform tasks such as cookie and token translation in the gateway.
APIM is one solution so I would favour that type of option if it improves your API security. There are other Azure options though, so it can be worth clarifying the types of things you want to do in gateways before choosing one. The API Gateway Guides may give you some ideas.
Based on what I've read, I still don't have a good understanding of what makes a workflow for authentication and resource request considered OAuth2. Does the following scenario I'm about to describe meet the requirements for OAuth2?
Step 1
I have a website that sends the following code via JavaScript:
// login to get an access token in json web token format
const jwt = null;
fetch('/login',{method:'POST',headers:{'Content-Type':'application/json'},body:JSON.stringify({username:'john',password:'pass'})})
.then(r=>r.json())
.then(r=>jwt = r.accessToken)
Step 2
When I want to get information from API, I do something like:
// list all my invoices
fetch('/invoices',{method:'GET',headers:{'Content-Type':'application/json','Authorizaton':'`Bearer ${jwt}`});
Does my workflow above meet the requirements of an OAuth2 implementation?
When I try to authenticate and request resources from other APIs such as Facebook, LinkedIn etc... there are more steps involved during the login process where I need specify hmac tokens, scopes, and redirect_url to get a client_secret. Then I use the client_secret to request the access_token. Does OAuth2 mandate that I also implement a workflow that incorporates scopes, redirect_url, and client_secret? Or is my initial scenario above adequate to satisfy OAuth2?
What you described is resource owner password credential grant type:
The credentials should only be used when there is a high degree of
trust between the resource owner and the client (e.g., the client is
part of the device operating system or a highly privileged
application), and when other authorization grant types are not
available (such as an authorization code).
The only case where I can imagine the usage of this gran type is your official mobile application.
OAuth2 is designed to be used in many types of applications (browser clients, daemons, native application etc.). That's why it has a few grant types.
Also OAuth2 uses principle of least privilege. That's why it has a concept of scopes i.e. client application should explicitly says what areas of your application it want to access.
I'm trying to implement authentication/authorization in my solution. I have a bunch of backend services(including identity service) under API Gateway, "backend for frontend" service, and SPA (React + Redux). I have read about OAuth2.0/OpenIdConnect, and I can't understand, why I shouldn't use Resource owner password flow?
A client ( my backend for frontend server ) is absolutely trusted, I can simply send users login/password to the server, then it forwards them to Identity server, receives the access token && refresh token and stores refresh token in memory(session, Redis, etc), and send the access token to SPA, which stores it in local storage. If SPA will send a request with the expired access token, the server will request a new one using refresh token and forwards the request to API Gateway with the new access token.
I think in my case a flows with redirects can provide worth user experience, and are too complicated.
What have I misunderstood? What potholes I'll hit if I'll implement authentication/authorization as I described above?
OAuth 2.0 specification's introduction section gives one key information on the problem it tries to solve. I have highlighted a section below,
In the traditional client-server authentication model, the client
requests an access-restricted resource (protected resource) on the
server by authenticating with the server using the resource owner's
credentials. In order to provide third-party applications access to
restricted resources, the resource owner shares its credentials with
the third party
As a summary what OAuth wants to provide is an authorization layer which removes the requirement of exposing end user credentials to a third party. To achieve this it presents several flows (ex:- Authorization code flow, Implicit flow etc.) to obtain tokens which are good enough to access protected resources.
But not all clients may able to adopt those flows. And this is the reason OAuth spec introduce ROPF. This is highlighted from following extraction,
The resource owner password credentials grant type is suitable in
cases where the resource owner has a trust relationship with the
client, such as the device operating system or a highly privileged
application.The authorization server should take special care when
enabling this grant type and only allow it when other flows are not
viable.
According to your explanation, you have a trust relationship with client. And your flow seems to be work fine. But from my end I see following issues.
Trust
The trust is between end user and the client application. When you release and use this as a product, will your end users trust your client and share their credentials.? For example, if your identity server is Azure AD, will end users share Azure credentials with your client.?
Trust may be not an issue if you are using a single identity server and it will be the only one you will ever use. Which brings us the next problem,
Support for multiple identity servers
One advantage you get with OAuth 2 and OpenID Connect is the ability to use multiple identity servers. For example, you may move between Azure AD, Identityserver or other identity servers which of customer's choice (ex:- they already use on internally and they want your app to use it). Now if your application wants to consume such identity servers, end users will have to share credentials with your client. Sometimes, these identity servers may not even support ROPF flow. And yet again TRUST become an issue.!
A solution ?
Well I see one good flow you can use. You have one front end server and a back-end server. I believe your client is the combination of both. If that's the case you could try to adopt authorization code flow. It's true your front end is a SPA. But you have a backend you can utilise to obtain tokens. Only challenge is to connect front end SPA with back end for token response (pass access token to SPA and store other tokens in back-end). With that approach, you avoid above mentioned issues.
If I have an API secured with Azure Active Directory, what is the flow when an external API wants to talk to my internal API?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
Is this just an API to API call as normal or is this a special circumstance and needs handling a different way?
The special circumstance may depend on the confidentiality of the resources served by these api(s) and the level of security your application needs. In the end it is an api to api call only.
There are two approaches you can use if Azure Active Directory (AAD) is your Identity Provider for the entire application.
Application Identity with OAuth 2.0 client credentials grant provided by AAD. The calling API makes a request to AAD token endpoint with its client id, client secret (credential) and the application id (the unique id for the callee API) to receive an access token as response. This token is used as Bearer token to call the downstream API. In this approach client id, client secret, application id that are exchanged for an access token, are static values. Some one who has access to these values may find a way to compromise application security (highly unlikely).
The second approach is Delegated User Identity with OAuth 2.0. A request is made to AAD token endpoint with client id, client secret, the access token received as part of calling the tier1 API and a special on_behalf_of parameter to receive an access token, refresh token as response. We preferred this approach as it uses a dynamic value (access token from tier1 api) and also provides a refresh token.
You can read more about these approaches here
If you do not want to use AAD, you can use asp.net built in OwinAuthenticationMiddleware to generate and validate your own access tokens. As said earlier it all depends on your application requirements and implementation details, but in the end it is an API to API call.
Hopefully this is helpful, please let me know if you have any questions.
Thank you,
Soma.
oAuth is done for loggin user to a webservice (see also reference here).
Use OAuth to give your users access to their data while protecting their account credentials.
As another webservice wants to consume one of your service best way to do so is to have another authentication method in order to authorize
Other API, I assume you are talking of machines and not users (alias humans).
So best way is to provide another auth mechanism in order to authorize machines to connect to your API in a safe way.
A simple way to do a machine connection is using a private PKI with public/private key.
A good reference for PKI : http://docs.oracle.com/javase/6/docs/technotes/guides/security/certpath/CertPathProgGuide.html
What are some real-world scenarios for 2-legged OAuth?
Is it only applicable for mobile/desktop apps?
2-legged OAuth (aka. the Client Credentials flow in OAuth 2.0) is useful when a client wants to access certain resources without disclosing its primary client credentials to the resource API. The client would authenticate to an Authorization Server to get a derived token that it can present to the resource API to get access to the protected resources.
Getting the token and presenting it is done in a standardized and interoperable way without pestering the resource API with different authentication mechanisms. It also makes revocation of access easier because that is controlled in a centralized fashion on the Authorization Server, independent of the client's primary credentials. See also: How does 2-legged oauth work in OAuth 2.0?
It is applicable across mobile, desktop and web applications although keeping a client secret in mobile and desktop applications is arguably hard so it is most suitable in server-side environments.
A real world scenario is a batch script that fetches data from a remote API and processes it.
2 legged auth is for server to server authentication on behalf of the application with no end-users involved.
For example, your application on Google AppEngine makes a request to Datastore (Database from Google Cloud). This uses 2 legged auth with JWTs.
Instead, if your application makes a request on behalf of the end user to read the user's Google Drive files, 3 legged auth is used.