After some rudimentary testing I've gotten CAS to work with the Authorization Code Grant. This seems to be the only grant mentioned in the documentation. Does CAS support other grants outlined in the OAuth2.0 draft 2-31 section 4.3? What are the service endpoints?
I'm the creator of the OAuth server support for CAS and so far, it only supports the authorization code grant which matches pretty well with the CAS webflow...
Related
I looked at mule-oauth2.xsd and found only client credentials and authorization grant type elements. However, looking at the oauth2-provider:config it can be configured as supportedGrantTypes="RESOURCE_OWNER_PASSWORD_CREDENTIALS". If it does support resource owner password credentials, how can I configure an oauth2-client to retrieve a token? I am looking at retrieving a token from the OAuth2 provider using the oauth2:client. Here is an example of what I'm referring to, however, I want to achieve this for password.
<http:request-config name="requestConfigWithOAuth">
<oauth2:client-credentials-grant-type
clientId="${client.id}"
clientSecret="${client.secret}"
tokenManager-ref="tokenManagerConfig">
<oauth2:token-request tokenUrl="${token.url}"/>
</oauth2:client-credentials-grant-type>
</http:request-config>
#Breen-
yes Mule provides Password Grant type. I recently configured for my APIs. In API management console, when you generate a client application , it provides an option for different grant types to select which is out of the box from MULE. you do not have to do any set up for this. It is through API management console on Anypoint platform.
Let me know if any question.
MuleSoft supports the following authentication in Mule 3.8 client apps:
Basic Authentication
NTLM Authentication
Digest Authentication
OAuth2 - Authorization Code
OAuth2 - Client Credentials
See the docs.
I've been trying to learn some server side frameworks these days. I am not an expert of oauth2, but I had use an api with a team. They gave me an access using Resource owner credentials grant, with a grant_type as password, client_id and client_secret. I can log in on multiple browsers at the same time. As I have tried sails js oauth 2 and laravel passport oauth2. I got confused. Both of them using grant_type password revoke my old access_token. Using laravel passport and sails js oauth2 with grant_type password. I can log in only on one device or browser at a time. I'm confused which one is the right thing to do.
Is this how oauth2 really works? you can only log in and use one access token?
If this is the standard way, revoking the old access token. What type of grant type should I use. so my multiple devices can log in at the same time?
The behavior --- whether issuing a new access token invalidates existing access tokens or not --- depends on OAuth 2.0 server implementations. The OAuth 2.0 specification (RFC 6749) does not impose any restrictions on the behavior.
In fact, a certain OAuth 2.0 server implementation provides a feature to enable server administrators to configure the behavior. The following is a screenshot of the description about the configuration item ("Single Access Token Per Subject").
So, what matters is not grant_type but the implementation policy of the OAuth 2.0 server you are using.
OAuth terminology has been bothering me a long time now. Is OAuth Authorization as some would suggest or is it Authentication?
Correct me if I'm wrong but I have always read Authorization as being the act of allowing someone access to a resource yet OAuth doesn't seem to have any implementation that actually allows access to users to a given resource. All OAuth implementations talk about is providing a user a token (signed and sometimes encrypted). This token is then passed with every call to a back-end service endpoint where it is checked for validity, again not an OAuth concern.
Is OAuth Authentication (every article says it isn't) which I take it requires a user to provide credentials which in turn proves a user should/shouldn't have access?
So it seems that OAuth is not Authorization NOR Authentication since these have to be performed by other processes. So what the heck is it? Is it a process for communicating a token? Is it fluff word that really has no specific meaning?
It's hard to ask a question about this subject without sounding enigmatic and superstitious (ghosts and goblins) so I expect that answering this question won't be a simple thing either. Enter at your own risk.
OAuth is a specification for authorization
OAuth 2.0 is a specification for authorization, but NOT for authentication. RFC 6749, 3.1. Authorization Endpoint explicitly says as follows:
The authorization endpoint is used to interact with the resource owner
and obtain an authorization grant. The authorization server MUST first
verify the identity of the resource owner. The way in which the
authorization server authenticates the resource owner (e.g., username
and password login, session cookies) is beyond the scope of this
specification.
OAuth authentication?
Authentication deals information about "who one is". Authorization deals information about "who grants what permissions to whom". Authorization flow contains authentication as its first step. It is the reason people are often confused.
There are many libraries and services that use OAuth 2.0 for authentication. It is often called "social login" and It makes people more confused. If you see "OAuth authentication" (not "OAuth authorization"), it is a solution using OAuth for authentication.
OpenID Connect
OpenID 1.0 and OpenID 2.0 are old specifications for authentication. Those who made the specifications expected people to use OpenID for authentication. However, some people began to use OAuth 2.0 for authentication (not for authorization) and OAuth authentication has prevailed rapidly.
From a viewpoint of OpenID guys, authentication based on OAuth was not secure enough, but they had to admit that people preferred OAuth authentication. As a result, OpenID guys decided to define a new specification, OpenID Connect, on top of OAuth 2.0.
Yes, this has made people much more confused.
One-sentence definitions of OAuth 2.0 and OpenID Connect
OAuth 2.0 is a framework where a user of a service can allow a third-party application to access his/her data hosted in the service without revealing his/her credentials (ID & password) to the application.
OpenID Connect is a framework on top of OAuth 2.0 where a third-party application can obtain a user's identity information which is managed by a service.
(Sorry, these definitions are excerpts from the overview page of my company)
Definitions from a viewpoint of implementors
Authentication is a process to determine the subject (= unique identifier) of an end-user. There are many ways to determine the subject. ID & password, fingerprints, iris recognition, etc.
Authorization is a process to associate the subject with the requested permissions and the client application that requested the permissions. An access token represents the association.
See Also
Full-Scratch Implementor of OAuth and OpenID Connect Talks About Findings
Diagrams And Movies Of All The OAuth 2.0 Flows
Diagrams of All The OpenID Connect Flows
The Simplest Guide To OAuth 2.0
OAuth is an authorization protocol. It is not designed for authentication. Yes, there is a step in the OAuth process where the identity server authenticates a resource owner. The way it happens does not belong to the OAuth protocol. That is why OAuth does not concern itself about authentication.
OAuth performs authorization by giving an access token to a third party (service provider) and that party will be able to authorize access to the resource by presenting the token.
Let's say there is a requirement that a service provider wants to access resources (protected by an identity server) on behalf of the resource owner. So the resource owner will first authenticate and then will grant permission for the service provider to access specific resource. Then the identity server will issue an access token for service provider. Later the service provider can access the resource with that token.
Here, OAuth does not care about who is carrying the access token or trying to access the resources. It validates the access token, and lets the third party access the resources.
I now researched quite some time to understand OAuth 1.0a, OAuth 2.0 and OpenID Connect. I read their RFCs/Specs and still have one question regarding Google and their Authorization Code Grant on mobile.
OAuth 2.0 states in chapter 4.1.3:
The authorization server MUST require client authentication for confidential clients [...]
My Question:
How can Google ensure it's client authentication for a mobile client?
Thanks,
Dominik
I have been using OAuth resource owner credential flow previously for authorization.
However I would now like to consider using openid connect in pace of this, for authentication and authorization, and was wondering if the resource owner credential flow is supported in openid connect.
Yes, OpenID Connect supports all OAuth 2.0 grant types including Resource Owner Password Credentials Grant and Client Credentials Grant.
As we know, Authorization Code Grant and Implicit Grant are typical 3-legged flows including interaction between a client, an authorization server and a user. While the Resource Owner Password Credential Grant and Client Credential Grant are 2-legged which means the client uses pre-authorized scopes so that no interaction with the user is necessary, removing the need to perform one of the legs in the typical flow.
Here is a reference: Configuring an OpenID Connect Provider to enable 2-legged OAuth requests
The answer is YES. It is not explicit in the specification but OpenID Connect supports all OAuth 2.0 flows since it is an extension of OAuth 2.0.
The spec talks about the flows that involve browser redirect as they are more common, more secure and less brittle given that resource owner credentials only supports username and password and is only in the OAuth 2 spec for backwards compatibility.
In true SSO systems you'd want to abstract away from the method of authenticating the user at the OP/IDP. Involving a browser is a way to do that. In the Resource Owner Password Credentials flow the client "sees" the username/password of the Resource Owner unlike the other flows, which defeats the primary purpose of a federated SSO protocol like OpenID Connect where authentication mechanisms and credentials should be independent from the client/app. For that reason you won't see much use of ROPC in OpenID Connect, with an exception perhaps in intra-enterprise use cases.
But your mileage may vary wrt. support in specific OP/AS software and client libraries.
Yes. I also was finding answer for same question sometimes back. According to the OpenId Connect specification, It is recommended to use authorization code and implicit grant types for OpenId Connect requests. But it is not mentioned that other grant types can not be used. Therefore you can use any other grant types for OpenId Connect authentication request. There is some mail from the openid connect group, which has been discussed on this. Please find it from here. If your OAuth2 Authorization server supports it, I guess that it is fine to use it. As i know, most of the Authorization servers support it, as an example from here