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
Related
I am very confused about the difference between oauth2 tokens and json web tokens.
I have searched about these technologies and the result is ;
Open Id is a protocol and It uses JSON Web tokens to ensure the requests are coming from a trusted user.
A Json web token contains a few user information ( claims ) as encrypted with a private key of sts.
Oauth2 is a framework and we can manage the login operations between our users , clients and resources and third-party applications.
Identity Framework 4 is an Open Id connect implementations .net MVC library. The library has written with oauth2 specs and it implements Open Id.
This is the point I didn't understand. The Oauth2 framework already has its token implementation.
Where is the place of JSON web tokens in this scenario?
For example, we have a simple web application and a server which implements identity server 4.
When a user requested a page from web application user will be redirected to our identity server to login operation.
After successful login Identity server adds a cookie to our response and these cookıe contains a token.
We wıll use that token when requests the other secure resources .
These steps are clear for me. Where is the Jason Web token in this schenio ?
How can I use JSON web tokens in my client app?
Where can I reach my user claims?
The reason for JWT is given in the specs of OAuth2
Since OAuth 2.0 does not define a protocol for the resource server to
learn meta-information about a token that it has received from an
authorization server, several different approaches have been
developed to bridge this gap. These include using structured token
formats such as JWT [RFC7519] or proprietary inter-service
communication mechanisms (such as shared databases and protected
enterprise service buses) that convey token information.
Being an open-standard JWT has been largely adopted in security-related technology and protocols. It defines a compact and self-contained way for securely transmitting information between parties as a JSON object. This information can be verified and trusted because it is digitally signed
Let's explain some concepts of this definition further.
Compact: Because of their smaller size, JWTs can be sent through a URL, POST parameter, or inside an HTTP header. Additionally, the smaller size means transmission is fast.
Self-contained: The payload contains all the required information about the user, avoiding the need to query the database more than once.
There are a lot of sites explaining these things as well as numerous technology providers.
https://jwt.io/introduction/ for providing tutorials and free e-book
https://oauth.net/2/ for in-depth stuff
https://openid.net/connect/ for the new kid on the block
To answer your IdentityServer related questions. Authentication & authorization related information are usually encoded
access token
identity token
The application-specific information/payload in these tokens is encoded using JWT. JWT is mostly transparent to application developers if good libraries are provided - as is the case for IdentityServer. You will find answers to your questions in the excellent documentation for IdentityServer. How to extract user claims is covered as well. The project provides numerous client examples that cover typical AuthX setups out there. It takes time and commitment to get through it.
JSON Web Token (JWT) (RFC 7519) itself is independent of OAuth 2.0 and OpenID Connect. You can use JWT wherever you like.
OAuth 2.0 is a specification as to how to request and issue access tokens. The specification does not say anything about how access tokens should be represented. Therefore, access tokens may be random strings or may be JWTs. Some authorization server implementations generate random strings and issue them as access tokens, and other implementations generate JWTs and issue them as access tokens. See “7. Access Token” in “Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings” for further discussion.
OpenID Connect is a specification as to how to request and issue ID tokens. The specification says an ID token is a kind of JWT. In addition, JWT is used in other places in the specification. Responses from UserInfo Endpoint are either plain JSON or JWT. Request Objects are JWT.
In normal cases, a server which supports OpenID Connect can issue both ID tokens (which are JWTs) and access tokens (which are either random strings or JWTs). This may be making you confused. Reading the following articles may be of help.
Diagrams of All The OpenID Connect Flows
Diagrams And Movies Of All The OAuth 2.0 Flows
Looking at the Oauth2 specification, it says in section 6:
... the refresh token is bound to the client to which it was issued.
However, I can't find anything in the specification the explicitly states that the token should be bound to the requesting client also. I am assuming this to be the case, and the Introspection Extension seems to support that assumption, but I want to know if that is correct.
As an example, say I am using two applications that use Google as the Oauth2 Authorization Server. I'm assuming that Google will issue two different tokens, one to each application, and that the tokens can only be used by the client to which they were issued because they are bound to that client.
An access token can have various implementations. The one that is most widely adopted today is the "Bearer" token, in RFC 6750 https://www.rfc-editor.org/rfc/rfc6750. A Bearer token is not bound to the Client on purpose: it makes it easy to implement, lowers the barrier for adoption and caters for a wide range of use cases.
Assuming that a Bearer token cannot be easily stolen, it is acceptable to avoid binding it to a specific Client: the intended Client could indeed share the access token with another Client but it could just as well share the data that the access token permits access to if the token was bound.
In environments that demand higher security one could use a token that is bound to the Client as defined in RFC 7800 https://www.rfc-editor.org/rfc/rfc7800.
Yes, I think it is implicit in the specification that the access token should only be used by the application that the user authorized. Putting it differently - having something other than the authorized application use the token to access user data is pretty much the definition of a privacy failure, and is what authorization protocols are explicitly designed to prevent in the first place.
Now, in practice, I think that having one application use the access token from another would work fine in many OAuth 2.0 implementations. I don't thing the Token Introspection extension is widely used, and most access tokens are designed to be self-validating. Indeed, that's the reason why token stealing is a security risk. By contrast, the refresh token should only be useful when combined with the client secret, so it's "bound" to the client technically as well as philosophically.
After reading the article How To Control User Identity Within Microservices I've been trying to implement such access control scheme (Value and Reference Tokens), but after going through multiple other topics and examples in GitHub related to Spring Security + OAuth + Zuul, I couldn't find concrete examples on how this can be achieved. All the examples that involve JWT return User Details when the token is returned, and that is what I would like to avoid. The User Details should never reach the Client directly but should be passed to the backend services instead. The tutorial Spring Security + AngularJs has a lot of information on how to evolve an application towards a secure one, but uses an Access Token or mentions the possibility of getting the User Details directly via JWT.
This SO question, Using Zuul as an authentication gateway by #phoenix7360, is exactly the approach I've been trying to implement but it only supplies a brief overview of the configuration required to carry out this kind of security approach for microservices. Please refer to the image in this question for a clear picture of how it would go.
I can't fully get my head around how the Zuul Pre-Filter should be configured and what the Authorization Server's configuration should look like. As stated in both the article and the SO question, the flow would go something like this:
External (HTTPS)
The client authenticates against OAuth2 Server
OAuth Server returns an opaque Access Token (a UUID with no other information)
The client sends the request to the API Gateway with the Access Token in the Authorization header
API Gateway requests User Details to the OAuth Server with the Access Token in the Authorization header
OAuth Server checks the Access Token is valid and returns User Information in JSON format
Internal (HTTP/S)
API Gateway creates a JWT with User Details and signs it with a private key
API Gateway adds the JWT to request and forwards it to Resource Server
Resource Server verifies the JWT using API Gateway's public key
Note: API Gateway should return an error if OAuth Server indicates Access Token is no longer valid.
How would the ZuulFilter work? Does a new request need to be issued against the OAuth Server (for instance, via RestTemplate), or are these schemes supported with the current implementation? Is there any particular configuration required for the JavaConfig classes for both OAuth and Zuul? If someone knows of a working example that would be really helpful and would be great for future reference regarding this topic.
I'm using Spring Boot (1.4.0-M3) + Spring OAuth + Spring Cloud (Eureka, Ribbon, Zuul)
I know this question is very similar to the one linked previously, and if this is not the right way of doing it I apologize, but I thought a new thread would be better than asking for help on a SO thread that aimed at solving another problem.
Thanks in advance!
JHipster does a pretty good job in handling this issue. If I want to tell the login process briefly, first you do login, in time you fetch every information you need to pass to your below services (such as username,email,etc) then you pass them to your microservices.
you can see the link below from okta for more information
https://developer.okta.com/blog/2018/03/01/develop-microservices-jhipster-oauth
I am trying to enforce OAuth 2 in Bluemix for a suite of microservices via API Management. Am I right in the assumption that the API Management service will always act as an OAuth 2 Authorization Provider as opposed to only checking the validity of access tokens as an enforcement gateway? The latter would be what I really want to have though.
Ideally I would like to specify my own OAuth Provider Implementation with the means to issue, validate and revoke access tokens. Then having the API Management service as a proxy for my services ensuring that requests coming in carry a valid token.
Reading the documentation I am struggling to understand how the API Management was designed. Could somebody point me to the direction I am looking for, or alternatively help me to understand what the API management's role in the OAuth Flows, listed in the Security Schemes, is?
Thanks.
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