Is it possible to log user out of only a single client? I tried to search online but could not find anything for logging user out from only a specific client.
With OAuth2 authentication, you don't log in or out of an application. OAuth2 is about permission delegation using access tokens. There is also the single sign on (SSO) feature of OpenID Connect (OAuth2 extension).
So you can either log out of the SSO session, which will force you to enter your credentials on the next /auth request. Or you can revoke a token used by a client. But if you have a valid SSO session at the auth server, the client can request a new token without you entering credentials.
So I think you will need to change your requirements (for logging out) to be compatible with OAuth2 / OpenID Connect concepts.
Related
Does keycloak provide a way to support Personal Access Tokens, similar to Github, when I am using Keycloak to handle authentication and using the tokens it issues to secure my API? When my application is using a web browser then logging in via OIDC flow works fine, but how can I handle login from a CLI or a headless API script for my application?
I could support a password flow where I get back a JWT token after providing a username and password, but I assume once the user has configured 2FA or if they are using SAML on the backend then all bets are off as a username and password would not get you access. This is exactly why Github offers personal access tokens. Is there some way to implement something like this using Keycloak or do we have to build it in our own application and then accept those tokens in addition to the JWT.
What I would envision is Keycloak being able to generate and store personal access tokens in its user store that a user could generate and revoke via the UI that Keycloak provides to the user. My CLI could then use this token to obtain a JWT and then proceed with calling my API the same way a web browser or other client would.
Some support for utilizing OTP during CLI scripting was added in recent Keycloak releases. I've not played with it so far, so i can't present you any recipes. Try to start at Authentication -> HTTP challenge Flow settings.
Regarding to users token you can implement required functionality as an SPI extension to Keycloak (see Server Development section in docs). From my point of view there should be two components:
User token issuer
Custom authenticator that will be used in authentication flow for your client
Here is rough example:
Let User tokens be like UUID strings, so all user tokens could be stored in user attributes (Attributes tab in user's settings Admin UI).
Some of your APIs could introduce dedicated endpoint that will accept valid Access Token< generate new UUID User Token, store it in keycloak user attributes via Admin API and return this token to user.
Then we create custom Authenticator SPI implementation that will extract user token from direct grant auth request and validate it.
And last step is to properly configure direct grant authentication flow for corresponding OIDC client. This flow should work like default if no user token presented in auth request and should validate only user token and ignore other credentials if user token presents.
Keycloak "server development" docs and keycloak sources are very helpful with such king of tasks.
I am reviewing OKTA. I have two authorization servers configured, the default one and a custom one. I have a client (web app) that is configured and correctly logging in. I am getting back the expected id_token and access_token. The problem I am running into, is how do I call an api, that is expecting an access token from the second authorization server? How do I request an access token on behalf of the logged in user (default auth server) from the second auth server, without prompting the user to login again? This is all done in .net core mvc application.
In each of your applications you can check for an active Okta session. If found initiate the OIDC AuthN flow.
This is the endpoint on the client you can use to check for an Active Session
https://developer.okta.com/docs/api/resources/sessions#get-current-session
You can use the following authorize URL to get the access token or id token
{{url}}/oauth2/{auth server ID}/v1/authorize?client_id={client id}&response_type=token&response_mode=fragment&scope=openid&nonce=nonce&state=state&redirect_uri={redirect url}
Get the auth server ID from the URL when you see visit the server in the UI.
The above call needs an active session so if you signed the user the first time with 'default' auth server recently. You don't need to sign the user again to get to the token for the second auth server.
I have implemented an OAuth2 register workflow (in Java) according to rfc6749
I'm using GitLab as OAuth2 Provider.
After the user granted access to my application for his account, I get an OAuth Token (along with refresh token and other stuff), I am able to make API requests on behalf of the user, so this is working fine.
This way I can get the users e-mail adress which I use to create an internal user.
My questions are:
Is it practice to issue a token that is generated by my application for the user (along with the OAuthToken) or should I just use the token that has been issued by the OAauth Provider? (My App also has local auth with bearer tokens). This token will be used for further API - CLIENT communication (stored in Angular2 local storage as bearer)
How to do login only? When a OAuth User accesses my web service, how do I know that this user is a OAuth User and which OAuth Token belongs to him? How can the user login without providing e-mail or password? (The user has no password) I guess I have to redirect him to the OAuth Provider again, but I don't want my user to grant access everytime he logs in.
Answer 1:
Though you can use the token provided by OAuth provider, you SHOULD NOT use it considering the risk that may arise exposing it to the public.
Instead you should securely save the token provided by OAuth provider into the database and use another token for authentication of further api calls. (you could use JWT)
Answer 2:
There are two types of systems
Which always uses OAuth provider for identifying user. (Ex. Tinder)
Which provides both OAuth Login and Traditional login/signup. (Ex. Quora, Instagram)
If you want your application to follow 2nd approach, you should ask the user to create password for the first time when the user logs in using OAuth provider.
This will allow the user to log into your application by both methods, traditional as well as OAuth
To identify users of your application, you should either use HTTP session or issue your own tokens. Do not use tokens generated by the OAuth2 provider - they are meant to be used just by your backend (in role of an OAuth2 client).
To use an external authentication in your application, you probably want to use OpenID Connect, not a bare OAuth2. OpenID Connect extends OAuth2 and it's meant for authentication instead of the rights delegation. Then you use an implicit flow (instead of authentication code grant) with scope=openid, your frontend app (HTML+JavaScript) gets an ID token signed by the OAuth2 provider. After successful signature verification, your backend can trust that the client is the one described in the ID token (in its "sub" field). Then you can either keep using the ID token or generate your own token.
Can someone shed some light on the use case for me. We wave users who will be signing in to third party client applications. Using OAUTH2 framework, the client app will redirect to our site to authenticate. From my undestanding, the Authorization server will return a access token and an id_token (OpenID Connect).
1) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go back into the client application hours later, do they still have go through the whole redirect to our /authorization endpoint to re-authenticate?
2) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go to our site, do they have to login again to authenticate?
Basically, does OpenID Connect over OAUTH2 allow a user to sign in once and then not have to sign in again after subsequent visit to the third party app or our app?
Thanks.
It depends on two things:
a. if the client application maintains a session and that session has not expired yet, the user won't be redirected at all
b. in case the client session timed out, the user will be redirected but if the IDP still has an authentication session running, the user will not have to authenticate and will be sent back immediately to the client app with a new token.
It depends on the IDP session existence/timeout again
Essentially an Identity Provider authenticates users and decides how to do that. It can prompt for credentials but can also create and maintain authentication sessions for the user for (typically) a limited period of time which allows for true Single Sign On (SSO).
Also note that this behaviour does not depend on the exact protocol at hand (OpenID Connect, OAuth or even SAML): it would work the same for any protocol that redirects a user to an Identity Provider in a federated SSO system.
In OpenID Connect, the session at RP typically starts when the RP validates End-User's ID Token. ID token consists of expiration time. So if the user just leaves (not logged out) and the id_token is expired when he access the RP, then the end-user needs to re-authenticate.
If the end-user logged out from the relying party and the OpenID provider supported logout mechanisms such as OIDC session management, OIDC front-channel logout or OIDC back-channel logout, then all RPs sharing the same browser session will be logged out (SLO). Then the end-user needs to login to the OP again to access the RPs.
Hi I'm just getting started on the v4 CTP so I can see me posting some basic questions as I get my head around it. I want to create a service provider so I'm looking at the WCF Oauth2
The first thing is when I go to login what is the format of the OpenID for use with the provided database? What is the process for this. I assume I'll get redirected to a screen where I put my password? And that interacts with the database?
Cheers, Chris.
The sample OAuth2 Authorization Server's database merely contains a couple of sample client entries so that the sample client can make requests. It has a users table that is automatically populated by each user who successfully logs in using their OpenID. So to your question regarding the "format of the OpenID" to use, any valid OpenID 1.1/2.0 identifier will work.
The OAuth2 authorization server sample doubles as an OpenID relying party in this respect, but its OpenID functions aren't the meat of the sample -- there are other sample OpenID RP sites that demonstrate more functionality in that respect. But being that OAuth2 auth server and OpenID RP are coupled in this way, the flow is that:
User visits OAuth2 Client site and indicates to the client that it may request access to user's data on the resource server.
Client redirects user to authorization server so the user may grant permission.
Authorization server prompts the user to log in, if not already logged in.
User enters OpenID
Authorization server redirects user to their OpenID Provider to log in using some credential (username/password, infocard, etc.)
OpenID Provider redirects user back to authorization server.
Authorization server sample then asks the user "do you want to share resource [x] with client [y]?" User confirms.
Authorization server records that user authorized client [y] to access [x] so that future requests from that client for that resource may be auto-approved without user intervention.
Authorization server redirects user back to Client with authorization grant.
Client receives the grant along with the user redirect and uses a direct HTTP request to the auth server to exchange that grant for an access token (and possibly a refresh token).
Client then includes the access token in HTTP requests to the resource server to access the user's private data.
I hope that helps.