end_session endpoint seems to only be terminating session in postman

By: Josh Newlin user 29 Jun 2018 at 12:50 p.m. CDT

16 Responses
Josh Newlin gravatar
Hey all, Thanks for your time, the issue revolves around the end_session endpoint and confusion on what the Gluu server is seeing on it's end that is different from what I'm sending it. **Background:** I login with a user and get a token id to attempt to test the end_session endpoint. Currently, I am trying to call this url from a node application, using the request library as so: ``` const request = require('request'); require('request-debug')(request); var options = { method: 'GET', url: 'https://[hostname omitted]/oxauth/restv1/end_session', qs: { id_token_hint: 'e60964f1-8024-44f7-9ada-09234bf1da98', post_logout_redirect_uri: 'https://[hostname omitted]/' }, }; request(options, function (error, response, body) { if (error) throw new Error(error); console.log('REQUEST RESULTS:', error, response.statusCode, body); }); ``` I plug the token into this application and it fails to terminate the session. On the server side, oxauth.log shows this: ``` 2018-06-29 17:37:12,767 INFO [qtp2008017533-11] [xdi.oxauth.session.ws.rs.EndSessionRestWebServiceImpl] (EndSessionRestWebServiceImpl.java:149) - Failed to find out authorization grant for id_token_hint 'e60964f1-8024-44f7-9ada-09234bf1da98' and session_id 'null' ``` Here's node's trace: ``` $ node testnode.js { request: { debugId: 1, uri: 'https://[hostname omitted]/oxauth/restv1/end_session?id_token_hint=e60964f1-8024-44f7-9ada-09234bf1da98&post_logout_redirect_uri=[hostname omitted]', method: 'GET', headers: { host: '[hostname omitted]' } } } { redirect: { debugId: 1, statusCode: 307, headers: { date: 'Fri, 29 Jun 2018 17:37:12 GMT', server: 'Jetty(9.3.15.v20161220)', 'x-xss-protection': '1; mode=block', 'x-content-type-options': 'nosniff', 'strict-transport-security': 'max-age=31536000; includeSubDomains', expires: 'Thu, 01 Jan 1970 00:00:00 GMT', 'content-type': 'text/plain', location: '[hostname omitted]', 'content-length': '149', 'set-cookie': [Array], connection: 'close' }, uri: '[hostname omitted]' } } { request: { debugId: 1, uri: '[hostname omitted]', method: 'GET', headers: { referer: 'https://[hostname omitted]/oxauth/restv1/end_session?id_token_hint=e60964f1-8024-44f7-9ada-09234bf1da98&post_logout_redirect_uri=[hostname omitted]', host: '[hostname omitted]' } } } { response: ... } ``` So, interesting, it fails. Note, it says it failed to find out authorization grant for id_token_hint, but if I try this same thing in Postman: ``` <!DOCTYPE html> <html> <head> <script>window.onload=function() {window.location='[omitted hostname]'}</script> <title>Gluu Generated logout page</title> </head> <body>Logout requests sent. <br/> </body> </html> ``` And the session is terminated with no new lines in oxauth.log. Interesting. So, it must be the requests library in my node application, right? Let's try CURLing the url to see if that works. First, I'm going to generate a new token, since the session was terminated successfully by Postman. ``` 2018-06-29 17:40:40,472 INFO [qtp2008017533-18] [org.xdi.oxauth.auth.Authenticator] (Authenticator.java:357) - Authentication success for User: '[omitting user info]' ``` And let me plug this new token into the command line: ``` curl -X GET \ 'https://[hostname omitted]/oxauth/restv1/end_session?id_token_hint=d95df1ed-1277-47cf-b2b8-2969be4c3d60&post_logout_redirect_uri=[omitted redirect]' ``` Result: ``` {"error":"invalid_grant_and_session","error_description":"The provided access token and session state are invalid or were issued to another client."} ``` And in oxauth.log, we see a familiar message: ``` 2018-06-29 17:43:53,711 INFO [qtp2008017533-14] [xdi.oxauth.session.ws.rs.EndSessionRestWebServiceImpl] (EndSessionRestWebServiceImpl.java:149) - Failed to find out authorization grant for id_token_hint 'd95df1ed-1277-47cf-b2b8-2969be4c3d60' and session_id 'null' ``` Let me try that same token in Postman now: ``` <!DOCTYPE html> <html> <head> <script>window.onload=function() {window.location='[hostname omitted]'}</script> <title>Gluu Generated logout page</title> </head> <body>Logout requests sent. <br/> </body> </html> ``` Session terminated successfully, and all is well! Except it still doesn't work in node or elsewhere. Any ideas? I just wonder why it failed to find out authorization grant for id_token_hint when the token is valid and displayed correctly. I wouldn't have written this support ticket if I didn't think something was up on Gluu's end, because, according to the oxauth.log, the request gets through regardless of how it's executed. Every time I request with node, I see: ``` Failed to find out authorization grant for id_token_hint 'xxxxxxxx' and session_id 'null' ``` in the oxauth.log. So why is this token not being recognized by anything else other than postman's request? It obviously receives the correct token, and a valid one! Thanks so much! Josh N.
Rhel 7.3
closed

Answers

By Aliaksandr Samuseu staff 29 Jun 2018 at 1:27 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Josh. First, there are [few known issues](https://github.com/GluuFederation/oxAuth/issues/831) with `/end_session` endpoint. For now, it's suffice to say that it actually doesn't need any parameters being sent to it to end session - as long as you also pass cookies related to the session in question. It may throw different kind of errors in some cases - yet it usually still kills the session anyway. So if your Node.js code can't end session, may be it's because you don't preserve and send cookies which were set during login when it was created? Then, your `id_token_hint` is not very usual as well. Judging by its value - 'e60964f1-8024-44f7-9ada-09234bf1da98' - I can only guess you are using access token as the hint, approach which was used in the past by Gluu indeed (and still is supported as legacy mode, afaik), but if you want compliance with the spec, you must send the id_token itself you got previous for this session in this parameter. Again, even if it's not able to find such hint, it still normally is able to end session, assuming you sent correct cookies as well.

By Aliaksandr Samuseu staff 29 Jun 2018 at 1:29 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Actually, `endSessionWithAccessToken` by default is set to False, so this legacy mode is not enabled OOTB. So if you don't send cookies as well, it's a normal outcome for oxAuth to not be able to terminate the session.

By Josh Newlin user 29 Jun 2018 at 1:48 p.m. CDT

Copy
Josh Newlin gravatar
Thanks for the quick response! I tested the cookie theory in Postman, and sure enough, once you delete the cookies it no longer works anymore! So the issue was, in fact, the lack of cookies in my node.js code. I will test this out before Tuesday and reply back here! Thanks, Aliaksandr. PS: I tried passing only the cookies, but it failed still. However, if I include the id_token_hint, as shown in my original post, and the cookies, it succeeds. Josh N.

By Josh Newlin user 29 Jun 2018 at 1:49 p.m. CDT

Copy
Josh Newlin gravatar
Also, is there a way to enable the `endSessionWithAccessToken` field in the Gluu configuration? Just in case we're not able to grab and store the cookies on login.

By Aliaksandr Samuseu staff 29 Jun 2018 at 1:51 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
> I tried passing only the cookies, but it failed still Are you sure? From my previous experience it threw an error page, but still session was killed anyway. >is there a way to enable the endSessionWithAccessToken field in the Gluu configuration? Yes, search for this settings on JSON configuration - > oxAuth page

By Aliaksandr Samuseu staff 29 Jun 2018 at 1:52 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
..though keep in mind it's definitely not recommended and against the spec.

By Josh Newlin user 02 Jul 2018 at 2:54 p.m. CDT

Copy
Josh Newlin gravatar
Hey Aliaksandr, We are not able to use the cookies method, due to our middleware implementation. I've enabled the endSessionWithAccessToken setting in the oxAuth JSON configuration screen. This, however, still does not seem to terminate the session when given the id_token nor the id_token_hint. It generates the "Logout request sent" page, however the session is still active. Is there something we're doing wrong? How can I get this session to terminate? Here's their request: ``` https://[hostname omitted]/oxauth/restv1/end_session?id_token_hint=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJodHRwczovL29ydnQtaWFtLWRldi5yb3VzaC5vbmNsZWFyb2JqZWN0LmNvbSIsImF1ZCI6IkAhOTgyMS5CNzZCLkQ2NTkuNUQ5NyEwMDAxITM0OEIuQUVDMyEwMDA4IUZEM0EuMjg4QS5BNzMyLjFGNTciLCJleHAiOjE1MzA1NjA4OTgsImlhdCI6MTUzMDU1NzI5OCwiYXV0aF90aW1lIjoxNTMwNTU0MjgwLCJhdF9oYXNoIjoiWEdkZ3U4emtSN2E0ak5Cdl9ncmVRQSIsIm94T3BlbklEQ29ubmVjdFZlcnNpb24iOiJvcGVuaWRjb25uZWN0LTEuMCIsInN1YiI6IlZFQzRDTVlYZl8xTkV...&post_logout_redirect_uri=[omitted] ``` Here's the response: ``` <!DOCTYPE html><html><head><script>window.onload=function() {window.location='[omitted]'}</script><title>Gluu Generated logout page</title></head><body>Logout requests sent.<br/></body></html> ``` I've also tried it with just the access token too, no luck.

By Josh Newlin user 09 Jul 2018 at 2:55 p.m. CDT

Copy
Josh Newlin gravatar
Hey Aliaksandr, Any updates on this issue? Do I still require cookies when `endSessionWithAccessToken` is enabled? Because it seems that it does not terminate the session with just the access token. Thanks! Josh N.

By Josh Newlin user 10 Jul 2018 at 8:32 a.m. CDT

Copy
Josh Newlin gravatar
Aliaksandr, It seems that the crucial element in the cookies is the `session_id`. I've included this in our request and it seems to function as expected. Is there any reason why we need this value, and can we progress with just the access token as the setting above dictates? I understand that including a `session_id` works, but I was just unsure if we absolutely needed that value included. Due to our middleware implementation, we have to send this session_id from the front end, and that adds unnecessary risk, and we really don't want that risk to have to exist in production. Thanks! Josh N.

By Aliaksandr Samuseu staff 10 Jul 2018 at 10:08 a.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Josh. Assigning to Sahil, he'll try to reproduce the issue.

By Aliaksandr Samuseu staff 12 Jul 2018 at 12:26 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
Hi, Josh. It's still assigned to Sahil, as far as I can tell. Just one question: when requests specified in [this post](https://support.gluu.org/access-management/5677/end_session-endpoint-seems-to-only-be-terminating-session-in-postman/#at35520) were issued, how much time have passed since the session was created?

By Josh Newlin user 12 Jul 2018 at 12:39 p.m. CDT

Copy
Josh Newlin gravatar
Aliaksandr, Yes, I noticed this. I had gotten an email when it was assigned and hadn't checked the web-based ticket until today. I think these support forums don't refresh cache if it's outdated and I had to refresh to see the new reply. No problem! To answer your question, the request was made well within the 5 minute expiry of the token. Thanks, Josh N.

By Aliaksandr Samuseu staff 12 Jul 2018 at 12:49 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
I was able to reproduce your issue. The solution is to pass `session_id` parameter in your logout request; if passed the session will be terminated, and no cookes need to be included. This session id is issued during session creation in a response from authz endpoint, and also is stored in cookies, so there are options to how to retrieve it.

By Josh Newlin user 12 Jul 2018 at 12:54 p.m. CDT

Copy
Josh Newlin gravatar
Aliaksandr, Thanks for the effort put into this ticket! I appreciate it. Is there a way we can enable logging out with just the `access_token`, as the `endSessionWithAccessToken` setting indicates? The problem with using this `session_id` is our middleware implementation of it. We have to transmit the `session_id` from the frontend to our implementation, which is a security risk that we're not willing to put into production. The documentation is a bit outdated, and doesn't even include the `session_id` as a field to be inputted. Is there no way to get around requiring this `session_id`? I would like to log out with just the `access_token` or `id_token` if possible. Thanks for your time, I understand if this is something I cannot do. It seems the `access_token` isn't even needed in this example, the `session_id` is what actually locates the session to terminate. If this is so, what's even the point of the `endSessionWithAccessToken` setting? Why even input any tokens, when we can do it with just the `session_id`? I appreciate your effort, Josh N.

By Aliaksandr Samuseu staff 12 Jul 2018 at 2:04 p.m. CDT

Copy
Aliaksandr Samuseu gravatar
I don't think I can offer something like that at the moment, sorry. I've created [an issue](https://github.com/GluuFederation/oxAuth/issues/849) related to this case. But as you see, my primary concern here is the fact that though despite user thinks the session was ended correctly, in fact it wasn't, not the problem it creates for your use case. What you ask for constitutes an enhancement request for a very specific use case. This flow is called "frontchannel logout" for a reason, it assumes some kind of user-agent is involved, which usually has access to cookies; you effectively need to re-purpose a standard flow to suite your use case. You can suggest your enhancement in the comment section of the issue above, or create your own enhancement proposal at Github. If you'll decide to do so, I would suggest to provide a solid reasoning for this change, showing how it will make Gluu Server more useful for everybody, as usually it's the only case we agree to invest our own development time into it. Unless it's the case, we usually only accept such change requests from our paying customers. Also, IMO the more appropriate solution would be to use [backchannel logout flow](http://openid.net/specs/openid-connect-backchannel-1_0.html) which is designed to be used by backend services via direct connections, but as far as I can see, it's not supported by oxAuth atm. So you could instead put an enhancement proposal to add support for it, what seems to me would be much easier to justify as it would be useful for all Gluu's userbase. I'm closing this ticket for now, you can continue discussing it in the comments section at Github.

By Aleksandar Petkovski user 17 Jul 2018 at 6:01 a.m. CDT

Copy
Aleksandar Petkovski gravatar
Greetings. We are having the same problems on our testbed. My aim is to logout from GLUU after we get the access token. We get the token and I managed to logout the session with the following settings: -endSessionWithAccessToken = False in oxAuth configuration (default) We send with GET to the "/oxauth/restv1/end_session" these parameters: "session_state" : session_state, "id_token_hint": str(access_token), "post_logout_redirect_uri" : config.post_logout_uri With this indeed we get answer 200 (OK), and logout page is shown. But, when I try to login again, I still get the same session_id and session_state, which is wrong. I actually want the same as when we set the parameter sessionIdLifetime to some value, i.e. 30 seconds: Session is logged out and new session is activated when the user logs in again. Could you please write down the correct workaround, if it exists? And update the documentation with the correct info?

Post an answer