In my understanding, the Authenticator Server is in charge of Authenticate Code and Token, and the Resource Server need the Token to verify it.
So my solutions is that both them needs to connect the same OAuth database, or the Resource Server invoke the Authenticator Server to verify token, it seems they are coupled.
If I misunderstood something please correct me.
Thanks in advance.
You are correct: the Resource Server and the Authorization Server need to "understand" each other and thus can be considered coupled. They typically live in the same administrative domain. OAuth 2.0 has not standardized the interface between RS and AS in the core spec meaning that the connection between the two is implementation specific. There is a more recent extension specification that standardizes the API between RS and AS, which would make it easier to use an RS and an AS from different vendors/stacks: https://www.rfc-editor.org/rfc/rfc7662
As stated, you are correct. The OAuth 2.0 specifications do not describe how the Authorization Server and Resource Server interact.
UMA (User Managed Access) defines interfaces between authorization servers and resource servers that, by default, enable centralized policy decision-making for improved service delivery, auditing, policy administration, and accountability, even in a very loosely coupled "public API" environment.
-jim
Related
This is just a general question about microservice architecture. Why do 2 or more internal services still need token auth like oauth2 to communicate with each other if the outside world doesn't have access to them? Couldn't their apis just filter internal IP addresses instead? What are the risks with that approach?
Why do 2 or more internal services still need token auth like oauth2 to communicate with each other if the outside world doesn't have access to them?
You don't need OAuth2 or token authentication, but you should use it. It depends on how much you trust your traffic. Now in the "cloud age" it is common to not own your own datacenters, so there is another part that own your server and network hardware. That part may do a misconfiguration, e.g. traffic from another customer is routed to your server. Or maybe you setup your own infrastructure and do a misconfiguration so that traffic from your test environment is unintendently routed to your production service. There is new practices to handle this new landscape and it is described in Google BeyondCorp and Zero Trust Networks.
Essentially, you should not trust the network traffic. Use authentication (e.g. OAuth2, OpenID Connect, JWT) on all requests, and encrypt all traffic with TLS or mTLS.
Couldn't their apis just filter internal IP addresses instead? What are the risks with that approach?
See above, maybe you should not trust the internal traffic either.
In addition, it is now common that your end-users is authenticated using OpenID Connect (OAuth2 based authentication) - JWT-tokens sent in the Authorization: Bearer header. Most of your system will operate in a user context when handling the request, that is located within the JWT-token, and it is easy to pass that token in requests to all services that are involved in the operation requested by the user.
For internal services it's usually less about verifying the token (which in theory was already done by the external-facing gateway/api), and more about passing through the identifying information on the user. It's very common for even internal services to want to know who the requesting/acting user is for permissions and access control, and sometimes it's just easier to tell every service creator who needs user-scoping to accept a JWT in the Authorization header than it is to say, "look for the user ID in the X-COMPANY-USER-ID header".
You can implement very granular role based access control(RBAC) on the apis exposed by Microservices using Oauth which you can not do using filtering IP address.
I'm developing an authentication/authorization system in Node Js for a microservice based application.
I read some articles and documentation about the OAuth2 standard but I need some clarification for my use case.
Basically OAuth2 has some actors like:
Resource owner (user)
Client app (a web application in some OAuth2 grant flows like authorization code, implicit, password)
Authorization server
Resource server (service I want to access to)
So in my database I store a client (web application) with its client_id and client_secret.
Let's suppose that one of my microservice needs to access data from another microservice. Both of them espose a REST Api.
There is no interaction with user, all is done in the background. In this case I would use the client credential flow.
Following OAuth2 rules, both of them are resource servers but in the same time it looks like they are client apps as well.
So should I register them in the client DB table/collection with client id, secret etcetera or did I make some mistakes?
Thank you
If I understood your question correctly, the caller micro-service is your client and the one that is being called is your resource. A lot depends on what type of micro-service communication pattern have you implemented. If you are implementing an "API Gateway" pattern, then your Gateway is always client and all other micro-services can be treated as resources. But if your micro-services can call each other then like you mentioned each one of them have to be registered as client and resource at the same time.
I was reading the OAuth 2.0 RFC 6749. In section: (Protocol Endpoints)[https://www.rfc-editor.org/rfc/rfc6749#section-3] it mentions that the Authorization server needs an authorization endpoint.
In the application I am building, there is a need for another client that wants a different way of completing the authorization code flow, hence was considering two options:
expose a new endpoint on a different path
retain existing endpoint (/authorization) but watch for headers that the new client will provide
The spec does not say anything about exposing multiple Authorization endpoints. Was wondering if it would be compliant?
I think that a "different way of completing the authorization code flow" may well be out of compliance with the specifications. Depends on the details. Generally, the Authorization Server may manage the authorization code flow internally as it sees fit based on "policy". However, externally, authorization code flow is well defined.
As the specifics of the Authorization_endpoint (RFC 6749): "The means through which the OAuth Client obtains the location of the Authorization_endpoint are beyond the scope but the location is typically provided in the service documentation."
The location may be defined in OpenID Connect Discovery or provided in the service documentation.
-jim
Currently, I think my understanding of OAuth and how it it is implemented in ASP.NET Web Api is flawed.
1) I keep seeing OAuth described as a server (i.e. the OAuth server). Is the OAuth implementation by a Microsoft a separate server with a different port or is it just referred to as a server even though it is self contained within the API project?
2) Is OWIN separate from OAuth or are the two linked such that they must be used together?
3) How does an OAuth v2 server keep track of tokens that have been revoked or have expired? Does the OAuth component have a database that keeps track of the tokens that it issues? If so, what type of database is it?
I have been reading the tutorials by Taiseer Joudeh from bitoftech.net but I think I am missing some of the basics.
Here are my responses:
You can implement the server as a stand alone authorization server or you can implement it together with the resource server. The Visual Studio template brings you both servers together, but you can separate them. Tutorials from Taiseer Joudeh will guide you very well, they did in my case.
OAuth 2.0 is an authorization framework, as said in its definition document. And OWIN stands for Open Web Interface for .NET. Both of them are different things, but Microsoft decided to do an implementation of OAuth 2.0 protocol using OWIN middlewares architecture. Then the easiest way to develop OAuth 2.0 servers in ASP.NET is using Microsoft.Owin.Security.* libraries implemented by Microsoft.
The OAuth 2.0 protocol does not talk about keeping track of expired or revoked tokens, you could implement if you want, but you only could do if the authorization and resource servers are both the same, and then you will need to access to database to check the token for each request, that it is not necessary. If the resource server is separated from the authorization server it has no direct access to the authorization server database. Normally you don't do that. The expiration check of the token is something that the Microsoft.Owin.Security.OAuth library makes for you. If a token received by the resource server has expired, the library responds with a 401 - Unauthorized response.
To make possible that the resource server can decrypt the token, you only need to set the same machine key in both servers' web.config file.
To avoid to have long lived access tokens you could set short access token timespan and implement refresh token. In this case, you could save refresh tokens in database and you can implement some method to revoke them.
Refresh tokens and its revokation are implemented in Taiseer Joudeh blog posts too.
I hope my explanations are clear and can help you. Please tell me if you have any other doubts.
Does OpenId support a two way exchange of tokens at any place in the spec? Specifically allowing both parties to share tokens with each other in some way so they can share services with each other?
I've looked through the spec, but can't see anything detailing any scenarios like this.
An app I'm working on has integrated itself with a trusted OpenId provider, we'll call Acme.
We'd also like to provide access tokens and refresh tokens to Acme, as they'd like to access features of our service as well.
It seems natural that during our interactions to get tokens from Acme, that we'd like to expose tokens to them.
Is this part of the spec in any way? Or is the only way to do this is to become a full identity provider ourselves?
You could include the tokens as part of a request object, see: http://openid.net/specs/openid-connect-core-1_0.html#RequestObject but that would depend on a pair-wise agreement with Acme since they'd need to handle the non-standaridzed request object contents.
The best way forward is to become a provider yourself so you can leverage all the features of the various flows without being dependent on a pair-wise agreement and accompanying implementation.
It sounds like you're confusing OpenID Connect and plain OAuth2 to some extent.
OpenID Connect is a specification for identifying end users to a client application, based on their authentication at the OpenID Provider. It's not clear from your question whether end users are even part of the picture, so even plain OAuth2 may not be relevant (unless you are just using the "client credentials" grant).
Neither spec says anything about mutual exchange of tokens. It would probably help if you describe the interactions you anticipate in more detail and which grants you expect to use. Who will authenticate to your identity provider and what would be a typical client application?