I got a problem and better if you could reply as soon as possible. we are using OIDC auth code flow to authenticate our application with oneLogin. We want to implement a logout function, but the issue is when revoke token and redirect to our application home page if the user is lpogged in to oneLogin, it sends user back to the oneLogin and authenticate again which makes impossible to log out from our application.
So my question is, do we have any way to log out user from oneLogin, therefore when the redirection happens user's credentials are requested again?
Or is there any suggested way to implement OIDC auth code flow which circumvate this logout issue?
Revoking the OIDC token only invalidate the token for your application. It does not kill the session the user has with Onelogin. You can remove the Onelogin session using the Log User Out API.
https://developers.onelogin.com/api-docs/1/users/log-user-out
Related
I am using B2C custom policies.
I am using Web.TPEngine.Providers.SelfAssertedAttributeProvider documented here:
https://learn.microsoft.com/en-us/azure/active-directory-b2c/self-asserted-technical-profile
The signin relying party of the custom policy is working well, except users won't get user/password challenge after a successful login. I guess the technical profile uses browser cookies like "x-ms-cpim-cache|o4wex_p_gejeeak6w_0" for domain b2clogin.com to remember a successful login for at least a browser session.
The Metadata "setting.enableRememberMe" is the default that is set to false.
I need to make sure users are challenged with user/pwd every tinme the signin relying party is called. Is there any way to disable the auto-login with the cookie cache?
Set the session management technical profile to SM-Noop on the sign in technical profile.
For JavaScript apps, this will break silent token calls for an access token.
Other option, for initial logins, send the query param prompt=login which will kill the cookies when the user arrives at B2C. This at least keeps silent token calls working for JS apps.
I am using Keycloak to secure my react front-end and node.js back-end. These clients are protected using role based authorization.
My front-end application registered in Keycloak as a public client and back-end registered as bearer only client. When a user logging in to the front-end, i am taking the access token for that particular user and i am using that access token to call back-end api layer.
When user logout from the front-end i am clearing the front-end client session of that particular user from Keycloak by using keycloak object logout method. That is working fine and user is logging out and redirected to the Keycloak login page.
But the issue is i can still use the access token of that logged out user to call back-end api. The access token is still valid even though the user logged out.
I tried this end point to revoke the user access token. But didn't work
/auth/admin/realms//users/
Is there a way to revoke the access token of a particular user in Keycloak ?
I think you can only revoke sessions but not issued access tokens. So the only solution for this is to choose a very short access token life span in combination with silent refresh, so the usability is still good and the maximum access time after session revocation is equal or less than token life span.
EDIT: There is an official guide about how to handle compromised tokens. They do not mention how to revoke an individual access token, so there is no documented way to do so. However, you can revoke all issued access keys by the described "not_before" way.
It's possible at least on KC 17.0 via /protocol/openid-connect/revoke but since it's auth endpoint, you have to provide both the token and client_id, because the server must validate if the token belongs to that specific client that's calling.
This means that along with client_id, you may also need to send a client_secret or whatever other accepted of authenticating the client app to the server -- much like it was done earlier while obtaining the token on /protocol/openid-connect/token.
Also worth noting that the token must be passed as POST form param or GET query param of that name: token, and not as a bearer header/etc.
BTW. Refresh tokens can be revoked with the same /openid-connect/revoke endpoint in the same way as access tokens, while the older, easier to find /openid-connect/logout still only handles id tokens and refresh tokens (POST a client_id, client_secret etc, and also either refresh_token or id_token_hint to be killed) and still rejects any attempts with access token. At least on KC 17.0
BTW. I have no idea if /revoke can handle id tokens. I doubt it, but RFCs seem to allow that as custom extenstion. I have not tried with KeyCloak 17.0
You could call the following endpoint to revoke an access token using a post
{serverName}/auth/realms/{realmName}/protocol/openid-connect/revoke
I'm new to using Azure Active Directory authentication with a Web API. Right now the login page on my Single Page Application simple directs the user to the Microsoft login page where they enter their credentials and then are redirected back to my SPA. Upon the redirect the access token is now part of the URL. Is it possible to get that token via JSON rather than part of the URL? Is that a security risk making the token visible to user like that? If there is no other way to get the token what's the best way of processing that? Should I read the URL and pull the token from there and then redirect the user again to the actual website?
You have to be mindful in implicit flow the token will still be maintained at the client site (local storage normally). So even if you are hiding the token from URL , you still will be storing at client side and that's one of things you have to manage in SPA. You will have to send token with every HTTP request to your web api to get that authenticated on that end.
In implicit flow tokens are shortlives and you can't issue refresh token for longer period of access. For this kind of flow you need to use official library (ADAL.js)
https://github.com/AzureAD/azure-activedirectory-library-for-js
More resources
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow
You can use ADAL.js library to acquire the token. There is a pre defined function which you have to call after the Ad authentication or at the beginning check if you are logged in, you can use isauthenticated function to check if you have already logged in, and use getaccesstoken function to acquire the token after authentication.
O.K this is driving me crazy
I am using this node module
to perform oauth authorization. I can get the password grant working since it involves just sending the right headers to the token endpoint. Nice and simple.
Now I want to authorize using the authorization_code grant. However, I need an access token or session to determine what user I am. This issue talks about how to do that.
I am still a bit unsure about a few things after reading the issue:
Should I get the initial user token from password grant?
Should I have access tokens to signin users and access tokens to sign
clients?
One has only user info the other has user and client info.
OR, Should I implement a users session in my oauth server?
Thanks in advance
I'm using the Kentor/SampleOwinApplication and I can successfully sign in and out from my Idp. Now I've made some tests with revoked users in the Asp.Net database. After successful federation signin and back into ExternalLoginCallback, SignInManager.ExternalSignInAsync returns LockedOut and I land on the revoke page.
The problem is I'm not signed in for Asp.Net but I'm still for my Idp, so if I try to log in again, I'm considered already signed I am redirected instantly back to my service without the chance to try to log with another user.
I understand I would need to log out from my IDP when in the LockedOut status but it seems hard to do with Kentor because specifically I'm not signed in on the Asp.net site!
Interesting border case!
What you should do is that when in the ExternalLoginCallback when you find out that you are locked out, you should kick of a federated logout by initiating a logout with the external identity as an argument. That will redirect the user to the Idp and invalidate the Idp session.
Note that this might have side effects if the user is already logged in to other services from the same Idp. Those other services will be logged out too.