This observation pertains to CAS 5.3.9 and the documentation under https://apereo.github.io/cas/5.3.x/installation/OAuth-OpenId-Authentication.html
There is no mention of a /callbackAuthorize endpoint and yet I am seeing this in my implementation of an Authorization Code flow. Here is the sequence of requests (we are assuming the user is already authenticated to CAS):
REQ: GET https://localhost:8145/api/profile (a protected endpoint of my application)
RESP: 302, Location: https://cas-server:8443/cas/oauth2.0/authorize?response_type=code&client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf
REQ: GET (URL above)
RESP: 302, Location: https://cas-server:8443/cas/login?service=https%3A%2F%2F172.16.238.10%3A8443%2Fooscas%2Foauth2.0%2FcallbackAuthorize%3Fclient_id%3Dclient1%26redirect_uri%3Dhttps%253A%252F%252Flocalhost%253A8145%252Fcallback%253Fstate%253Dcsrf%26response_type%3Dcode%26client_name%3DCasOAuthClient
REQ: GET (URL above)
RESP: 302, Location: https://cas-server:8443/cas/oauth2.0/callbackAuthorize?client_id=client1&redirect_uri=https%3A%2F%2Flocalhost%3A8145%2Fcallback%3Fstate%3Dcsrf&response_type=code&client_name=CasOAuthClient&ticket=eyJhbGciOiJIUzUxMiJ9.ZXlKNmFYQWlPaUpFUlVZaUxDSmhiR2NpT2lKa2FYSWlMQ0psYm1NaU9pSkJNVEk0UTBKRExVaFRNalUySW4wLi5RdURKNXBJZ21zOU1LcldqSmwxMk5BLnRXb3FrSEFIRzcyY2M3U3k4cm9fR0VCS05feThtVjREazBYNU81NVNVY3g0NEFlby1Kc2R3NGszNUM3X1dDVkwuM01Pd3c5ci1mVS1QelROWDVIZkJSUQ%3D%3D.b4rotud6-2s3tOU21-Y0xclwVkVEioTLhiyRhi5VotNfjzt5vKoM2Ix9Hy_OW9KSpuGMqWsBbFOtR9K2B8E6dw&lang=de
REQ: GET (URL above)
RESP: 500, Internal Server Error (cas server log shows SSL Handshake exception, probably the server tries to access a URL he has no certificate for in his truststore)
My questions:
1) Is there any documentation for the /oauth2.0/callbackAuthorize endpoint?
2) Why is the CAS server issueing a ticket in an OAuth2 flow? Should he not produce an access token instead?
3) Where is the parameter client_name=CasOAuthClient coming from? Is the CAS server trying to act as an OAuth2 client?
1) Is there any documentation for the /oauth2.0/callbackAuthorize endpoint?
Yes. See this link for general design notes, and then take a look at how pac4j works.
2) Why is the CAS server issueing a ticket in an OAuth2 flow? Should he not produce an access token instead?
No. Authorization code flows issue ATs via the access token endpoint. If you need ATs from the authorization endpoint, you need to use a different grant type. See the OAUTH spec for more.
3) Where is the parameter client_name=CasOAuthClient coming from? Is the CAS server trying to act as an OAuth2 client?
From the above link,
... almost all protocols supported by CAS operate with the same exact intentions. A given CAS deployment is equipped with an embedded “plugin” that knows how to speak SAML2 and CAS, OAuth2 and CAS, or OpenID Connect and CAS or whatever. The right-hand side of that equation is always CAS when you consider, as an example, the following authentication flow with an OAuth2-enabled client application:
The CAS deployment has turned on the OAuth2 plugin.
An OAuth2 authorization request is submitted to the relevant CAS endpoint.
The OAuth2 plugin verifies the request and translates it to a CAS authentication request!
The authentication request is routed to the relevant CAS login endpoint.
User authenticates and CAS routes the flow back to the OAuth2 plugin, having issued a service ticket for the plugin.
The OAuth2 plugin attempts to validate that ticket to retrieve the necessary user profile and attributes.
The OAuth2 plugin then proceeds to issue the right OAuth2 response by translating and transforming the profile and validated assertions into what the client application may need.
Also, extracted from this link:
... all protocols are clients of the CAS server that interact with it using the CAS protocol. This is done at the request/browser level, as opposed to doing things internally via heavily customized webflows and such that would be entangled with one another. The protocol modules that exist in CAS make zero assumptions about the internal inner workings of the CAS authentication flow/engine. They treat it just like they would an external CAS server; the only difference is, they sit and live inside the CAS server directly and yet they remain completely agnostic of that fact. Simply put in our example, the SAML2 module basically says: “this incoming request needs to be authenticated. So I’ll route it to a CAS server for authentication and when it comes back, I’ll do my bit”.
Related
I am using OpenID Connect in Keycloak as an authentication solution and I've just encountered the following scenario.
Client A sends an authorisation request to the Authorization server and provide redirect_url of client B in that request.
Authorization server authenticate the user and redirect the user to the provided redirect_url(which is for client B) with authentication_code.
Client B communicates with Authorization server with its own client_id and secret and takes its token.
I want to know why OpenID Connect has allowed this
process, is it a normal thing for a client to initiate authentication for another client? Why the issued authentication_code is not bound to the client who has initiated the authentication and why it the authentication_code can be used by other client with other client_id?
Note: I know that validity of redirection_url will be checked in that process but I want to know why authorization code is not bound to client_id itself.
If it's indeed possible in Keycloak then it's a problem of the implementation, not the spec. The Oauth spec in section 4.1.2. indicates this for the authorization code:
The authorization code is bound to the client identifier and redirection URI.
As for the redirect URI it should also be verified and client A should be able to use redirect URI of client B only if that other redirect URI was whitelisted for client A.
The Proof Key for Code Exchange is also something which would prevent such a use of an Oauth flow as you described here.
I am looking for fittings ends to our SSO puzzle.
Currently we have an OpenLDAP behind WSO2 Identity Provider. A client (Service Provider) redirects authorization to the IP (OAuth2) and recieves an access_token.
All fine.
Next step is to validate this token on another Service Provider, in this case a reverse proxy (Apache or Nginx) residing on another EC2 instance, which protects a number of unprotected 3rd party applications (3rd party in the sense that we can't touch source code, but do the hosting our selves). Which tools do serve this request?
Am am aware that the OAuth2 spec leaves a hiatus here and that there is draft which adds a /introspect call to validate this token. I also know that pingidentity implements this draft as part of there Apache module (https://github.com/pingidentity/mod_auth_openidc).
I am just wondering how to implement this on the WSO2-IS side, as I don't find documentation.
*bonus: we also hit several errors while deploying WSO2 (SQL errors) and using it (https://wso2.org/jira/browse/IDENTITY-3009) which made us a bit distrusting about the product.
Oauth2 token validate may be performed with a SOAP call to
{WSO2_IS}/services/OAuth2TokenValidationService.OAuth2TokenValidationServiceHttpsSoap11Endpoint/
The response will include details regarding token validity and JWT claims.
Generally OAuth definition says that it is way where user gives an application access to his resources stored in other application (without exposing the actual username and password). But inside Owin, it is a way to implement token based authentication within an application. Although we can deploy the Authorisation application at different server. But crux remains the same. Could anybody shed some light. I am very confused.
Thanks in advance
If you take a look at the OAuth 2.0 spec you will find this:
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So basically, you have 2 options:
1) Use the authorization endpoint where your end-user is redirected to a form that is handled by the authorization server
OR
2) Create your own form inside your app, get the end-user credentials and send that data to the authorization server, where it will be validated and return a token for you to use.
You can implement the "Authorization Code Flow" in this situation?
A single page app in www.app.com
A REST backend in www.backend.com
Is possible to obtain via javascript an "authorization code" and then pass it to the "backend" for this get the "access token"?
In theory, using the authorization code flow (or the hybrid flow) with a JS/mobile/desktop application is definitely possible, and you don't even need to store client credentials for that (you could, of course, but extracting them is so easy that it would be pointless).
Contrary to popular belief, client authentication is not required for "public" applications (i.e apps that cannot safely store their credentials, which includes JS apps) when using the authorization code flow:
If the client type is confidential or the client was issued client
credentials (or assigned other authentication requirements), the
client MUST authenticate with the authorization server as described
in Section 3.2.1.
https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3
f the Client is a Confidential Client, then it MUST authenticate to the Token Endpoint using the authentication method registered for its client_id, as described in Section 9.
http://openid.net/specs/openid-connect-core-1_0.html#TokenRequest
In practice, I'm pretty sure most authorization/authentication servers will enforce client authentication when using the authorization code flow and will instead recommend using the implicit flow for public apps.
If your authorization server supports this scenario, using the authorization code flow in your JS app should be easy if you use response_mode=query (or better: response_mode=fragment as suggested by #Hans), since you can use your JS main page as the redirect_uri and use some JS to extract the authorization code from the query string or from the fragment.
That is possible by setting the redirect_uri to somewhere in your SPA, pickup the code from the authorization response (using any of the methods described in How to get the value from the GET parameters?) and pass it on to the backend in an application specific way. When using OpenID Connect there's the option to have the code delivered in the fragment of the redirect_uri which has some security advantages over having it delivered as a query parameter.
We want to set up our own OAuth 2.0 authorization server based on the following roles:
Resource Server - An API built with ASP.NET Web API
Client - A web application built with ASP.NET MVC
Resource Owner - The end user
We plan to use the password grant type (Resource Owner Password Credentials Grant) such that the Resource Owner will submit their credentials to the Client, who will in turn make an Authorization Request. We want to authenticate the Client Request with Basic Authentication.
I'm struggling with how to set up an Authorization server using DNOA that supports this grant type. I've downloaded the Authorization Server sample project but this appears to be using token based grants (user authenticates directly with authorization server - in the sample, via OpenID).
When I try and make an Authorization request using fiddler I'm just redirected to the login page, so I'm assuming this sample doesn't support this grant type:
POST http://localhost:50172/oauth/authorize HTTP/1.1
User-Agent: Fiddler
Host: localhost:50172
Content-Length: 103
grant_type=password&client_id=sampleconsumer&client_secret=samplesecret&username=user&password=password
The same is true if I use basic authentication.
Any help would be appreciated. I've used DNOA with great success in the past to consume OAuth services, but am finding the documentation on setting up/configuring a server pretty sparse.
It looks like you are sending the password grant to the authorization server's authorization endpoint which is wrong. Grants should go directly to the token endpoint, which must be at a URL that the authorization server does not require an authenticated request to access (i.e. won't cause ASP.NET to redirect to the login page).
That said, it's very unusual (and discouraged) for a web based client app to ask the user for a password to another web service. The authorization code flow is by far the preferred one for the scenario you sound like you're describing.