Recommend this page to a friend! |
PHP OAuth Library | > | PHP OAuth Library package blog | > | How Can the PHP OAuth... | > | All threads | > | What is the correct way to logout... | > | (Un) Subscribe thread alerts |
|
1 - 10 | 11 - 13 |
![]() What is the correct way to logout using the package?
I need to be able to logout, so that I can login again with a different identity. Currently, when I click my Logout link, I am deleting the OAUTH_STATE and OAUTH_ACCESS_TOKEN session variables, and also calling session_destroy(). However, when I click my Login link, I am logged in without having to re-authenticate, and the OAUTH_ACCESS_TOKEN session variable is back, with the same values. Apparently there is some state I am not clearing properly.
![]() The example scripts do not really "Login". They just retrieve a token that allows your application to call the server OAuth API to get the user details.
You can make it forget the token calling the ResetAccessToken class function, but the user may remain logged on the server of the API. Did you want to logout the user from the API server, i.e. from Google for instance, or just to forget the OAuth token?
![]() I have a Login button, which is replaced by a Logout button wh4n the user is logged in.
Currently, when I click Logout, I am deleting the S_SESSION['OAUTH_XXX'] session variables. All my scripts start with a session handler which checks the login status, and it appears that deleting those variables is sufficient for the session code (specifically CheckAccessToken()) to not recognise the user as logged in. However, when I click Login again, I am logged in without being presented with the login dialog, presumably because the cookies created by the identity server still exist and the server uses them to reestablish the context. I need a way to invoke the server such that it removes the cookies that it created. The session code executes the following: if(($success = $client->Initialize())) { if(($success = $client->CheckAccessToken($redirect_uri))) { if(!isset($redirect_url)) { if(strlen($client->access_token)) { $success = $client->CallAPI("https://$server:$port/oauth2/userinfo", 'GET', array(), array('FailOnAccessError'=>true), $user); if ($success) { $remote_user = $user->user_name; } } } } I am interacting with our own instance of the WSO2 server. It has a revoke operation, https://docs.wso2.com/display/IS500/OAuth+Token+Revocation+with+WSO2+Identity+Server, but as I read this it revokes the permission that the user grants to the app to use the server. So, while it might indeed logout the user, it would also mean that next time they would have to grant permission to the app again, which is not what we want to achieve.
![]() I see. Let me explain the different aspects.
What you do unsetting session variables is the same as calling ResetAccessToken. So use this function instead of accessing the session variables directly to preserve future compatibility. When you click on Login the class redirects to the authorization page. Since the user is still logged on the server site and he previously authorized your application, the site redirects back to you. This is pretty standard behavior. Some API like Google allow to force to prompt user login every time. I don't know about the API you use. You need to check the documentation to see if there is an option to force prompting the user every time the token is no longer available. In that case you can use that option the URL for the offline_dialog_url. Token revocation will not help to make the login prompt appear because it only revokes the token that the OAuth class already discarded.
![]() OK, I have been pursuing this with the WSO2 support folks, and I now have the right endpoint for revoking the token.
I am now wondering how best to invoke it using the library. The endpoint signature is: curl -X POST --basic -u "<client_id>:<client_secret>" -H "Content-Type: application/x-www-form-urlencoded;charset=UTF-8" -k -d "token=<access_token>&token_type_hint=access_token" https://<server>:<port>/oauth2/revoke I tried using the CallAPI function, but that generates an error, I believe because it does not invoke the endpoint with the correct signature. I did wonder if there was some way to invoke it in the same way as the dialog_url or the access_token_url, but again the signatures are different. I can invoke it directly using curl, but if there is a way to do it using the library, I would like to do so. Also, I would like to suggest that a revoke_url, and a corresponding Revoke_Access_Token function might be good additions to the library if you should ever be thinking about possible enhancements.
![]() OK, I just added token revocation support. Take a look at this example of logout from Google.
It really does not make the user logout from Google. It just invalidates the access token, so the package will need a new one next time, just like using the URL for that API you were recommended. Just let me know if it works well for you. phpclasses.org/package/7700-PHP-Aut ...
![]() Many, many thanks for your prompt enhancement. It will really be most helpful.
There is a line missing from the updated oauth_client.php. "revoke_token_url" needs to be added to the list of supported properties for non-builtin servers. I added 'revoke_token_url'=>'string', after line 2645 'access_token_url'=>'string', Without it, the Initialize function failed. The RevokeToken function seems to be working fine, and the server is returning information that it has revoked the appropriate access token. Unfortunately, this isn't quite doing what I need as it leaves the identity server cookies intact, and they appear to contain information, in a commonAuthId cookie, that means that when I try to login again, it does not require me to enter a username and pawword, which means that I cannot login with a different username without destrying the cookies manually or ending the browser session. This appears to be a server issue, so not solvable by any further changes in the client library. Hopefully the WSO2 folks will be able to explain what needs to be done in the application to cause the server to destroy the cookies.
![]() Yes, I already fixed that now. Thanks for reporting.
As for not logging off, that is what I suspected because token access and login sessions are independent activities. Maybe there is some more specific API calls for your purposes.
![]() I have been doing further research and testing, and besides the revoke endoint, there is also an oidc/logout endpoint which actually performa a full logout operation.
Looking at the spec for OpenId Connect Session Management, the oidc logout endpoint returns a redirect response, (http://openid.net/specs/openid-connect-session-1_0.html#RPLogout). Currently I am invoking the oidc/logout operation using the CallAPI function. If I do not set FailonAccessError = true, then no oauth_client error is generated when it receives the 302 response, but it does not follow the redirection contained within the response. It would be helpful if CallAPI followed the redirect either optionally or automatically. Alternatively, there could be a separate Logout function if the same way as you added a separate Revoke function. Currently the WSO2 server does not support the post_logout_redirect_uri parameter, but it will do in the next release.
![]() OK, thanks to the WSO2 support folks, I think I now know what the issue is.
Thr problem is that when I use CallAPI to send the oidc/logout request, it is not including the cookies set by the identity server iin the call. In nthe case of the WSO2 server, it needs to send the "commonauthId" and "opbs" cookies along with the request, and then, when it receives the 302 response, it needs to follow the redirection in the Location: header. It looks to me as if this is going to need to be covered in a separate function, rather than trying to build it in to the CallAPI function. I will investigate using the http library to create a standalone function, and if it works, I will post it here in case you would like to use it as a basis for a new function in the oauth-client library. |
1 - 10 | 11 - 13 |
info at phpclasses dot org
.