0

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?

ulim
  • 83
  • 10

1 Answers1

0

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”.

Misagh Moayyed
  • 4,154
  • 2
  • 15
  • 25
  • Thank you very much for this explanation. Turns out I was barking up the wrong tree! Just as a slight clarification to my second question: I was expecting the CAS server to issue "Access Tokens", but I misspoke. I really meant "Authorization Codes". In any event, now I know why service tickets appear at that point, the CAS Server is actually just doing the CAS workflow behind the scenes. It would be great to have some docs for what an OAuth2 authorization code flow would look like including the CAS requests. – ulim Apr 24 '20 at 12:59
  • On second thoughts: would this not be considered a violation of the OAuth2 protocol, if my browser is redirected to an internal CAS url like /callbackAuthorize? From reading your link I would assume that the plugin does these requests by itself, but I am seeing these redirects in my browser. – ulim Apr 24 '20 at 14:53
  • No. A protocol is an agreement between two entities. It says what inputs are accepted, what should be done with them and what should the output be. The rest is implementation detail. Its like you ordering pepperoni pizza and getting it. You don't care what oven was used or what the name of the cook is! If your order is satisfied, you are good to go. – Misagh Moayyed Apr 24 '20 at 16:58
  • Well, the response to my OAuth2 request (see above) is a redirect to a /callbackAuthorize endpoint, which I don't believe I ordered. But maybe I did unknowingly? Is there any documentation for this /callbackAuthorize endpoint? – ulim Apr 25 '20 at 17:44
  • Again, you don't receive that. You are the application, whatever happens inside the server or the kitchen is none of your business as the client. When you are contacted at the application level is when you receive the order. The rest is inconsequential and irrelevant to the client. There is no other documentation that I am aware of. – Misagh Moayyed Apr 25 '20 at 19:06
  • I'll re-open this question, perhaps someone else can chime in, who knows more about the internals of the CAS server and can explain those undocumented redirects. – ulim Apr 26 '20 at 23:27