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.
Related
I am trying to figure out how to perform single sign on with OAUTH2 on two different applications. Currently according to my understanding I can use the Authentication Provider in order to authenticate my clients. The procedure is the following:
The client is redirected to the Authentication Provider
Then the client is loggedin and has the code
The client provides the code to my application
The server uses the code in order to retrieve the access token.
Using the access token my server uses the remote API to retrieve information
Now I have a second application in a different backend (PHP) that I want to inform that the user is already loged in via the OAUTH. My naive solution is to provide the access token of the first application to the second application in order to perform the authentication. However, I understand that I am not allowed to share the access tokens between apps.
Every backend service should validate the access token via introspection. The only introspection guarantees that the token is valid, not expired or revoked.
So you have to pass the access token to the Backend service. To secure that you can use HTTPS API.
You are correct regarding not sharing the access token. The Authentication Provider should also allow creating an ID token. You would configure your second application with the authentication provider and get a client id. Both the client id and ID token are required to sign in the second app which will generate it's access token.
What grant type are you using?
Both apps need to redirect the user:
In the first app the user will authenticate and the app will get an access token scoped to that app.
In the second app the user will be automatically signed in without needing to reauthenticate. The app will then get a separate access token, generally with different privileges to that of the first app.
This is standard SSO behaviour and it is best to accept it. Usability is pretty good. Trying to share tokens is not advised unless you have advanced requirements.
I'm developing a set of microservices exposed as REST through WSO2 API manager.
Now, I'd like to call these services in Angular front end. What is the best way to handle user authentication and authorization?
I found it can be done through OAuth2 Password Grant as described here?
When user logs in, user credentials will be sent to specific WSO2 APIM endpoint (/token), it validates, generates the token and this token will be sent in header for subsequent calls.
Is this the best approach to this case?
Thanks in advance,
As mentioned in your question, https://apim.docs.wso2.com/en/next/learn/api-security/oauth2/grant-types/password-grant/
This method will only work when you have the resource owner's username and password.
Take an example, suppose you have published the APIs and created a user (resource owner) in the WSO2 store. this user is subscribed to the API using the application. the application will have a client id and secret, which will be used to generate the OAuth2.0 token. this token will be used to invoke the APIs.
Now in your angular project, one way is to hardcode the base64(clientid:clientsecret) and call the token API to generate the OAuth2.0 bearer token. use the generated token to call the APIs onboarded on WSO2. To protect your APIs from the attack, use rate limiting based on IP
Now take another situation, if you want the user to authenticate first, then generate the JWT token for that user using the password grant type (using actual user's username and password), and using that JWT generate the OAuth2.0 Bearer token which will be used to call the APIs.
Steps to be performed for the second situation:
during registration (from Angular), internally onboard the user in the WSO2 Identity Server. (There is a WSO2 API for the same)
After registration, generate the JWT token from the identity server by authenticating username and password. (Again for this, WSO2 API is there)
now using this JWT token, Generate the OAuth2.0 token from WSO2 APIM
use this token to call the APIs
The second approach is the ideal approach for user to service authentication and authorization using WSO2 as the gateway while the first approach mainly focuses on service to service authentication and authorization
Hope this answers your question
Reference Link: https://medium.com/wso2-learning/how-to-protect-your-apis-with-self-contained-access-token-jwt-using-wso2-api-manager-and-wso2-75673d8a4686
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 new to OAuth and OpenId, and after reading multiple pages and information I still do not feel confident at all.
My goal would be to create an iOS Application that communicates with my BE. I need the iOS app to authenticate the user to access their resources.
Reading about OAuth, the solution seems to be straight forward. Just use the Authorization Code Flow with PKCE to make the App have an Access Token. This way I am authorizing my iOS app to access user's data. When the iOS app calls https://example.org/user with the access token, the resource service (my BE server) can get the access token and call the introspection API to know to which user the access token is bound to, and return the correct user data. Since authorization needs authentication to be made in the first place, having the access token would mean that the user is (or at least was) authenticated.
First thing that confuses me: According to the OAuth specs, OAuth is not an authentication protocol, but still the protocol authenticates the user using the user's credentials. Why is OAuth asking the user for credentials, instead of relying on another protocol/flow for user authentication? Such protocol would just acknowledge to OAuth that the authentication was successful.
This first issue made me start reading about Open ID Connect specification and the ID Token. This token would be received by the iOS app. What is the iOS App supposed to do with it? I can already get the user information calling the /user endpoint. How would this ID Token be an advantage?
tldr
Access token (OAuth 2.0) - authorize against OAuth protected
endpoints.
ID Token (OIDC) - authentiation by client application.
Authorization server authentication - It's there to detect
authenticity of end user involved in both protocols (pseudo
authentication from client application perspective)
OAuth is not an authentication protocol, but still the protocol contain a step to authenticate the user using the user's credentials
Correct, OAuth is not an authentication protocol. It is for authorization, which means identifying there are correct access grants to access a protected resource (protected resource ? ex:- An API, A photo stored in a backend).
So why you see end user login dialog ? Well that is the job of authorization server. It authenticate end user to be known by it and then issue the access token to client (client == in simple terms the application which end user uses). So yes there is an authenitcation happening, but this is not applicable to your client application or protected endpoint. One can define this as an pseudo authentication.
OpenID Connect - For authentication of client application
In the original RFC (RFC-6749), OAuth 2.0 was defined as a framework. OpenID Connect was an extension that built on this framework. What it provide ? Well as you found out, it introduce the ID Token. And ID token is issued by authorization server to be consumed by your client application. It contains end user identity information in JWT format. By validating integrity of this token, your client application can authenticate the end user. And access token ? That's there to used against protected endpoint. It doesn't say anything about end user to client.
I am writing a web app, "B", that interfaces through a REST API with another web app, "A", that I wrote and control.
I would like for a user that is logged into A to be able to perform actions on B that use the API to communicate with A. My best option looks like OAuth, but I want the experience to be seamless, and OAuth requires that the user consent before an access token is granted.
Is OAuth a good solution for this situation? Is there a better alternative?
If I do use OAuth, can I pre-authorize consent by trusting the Consumer Key?
You can do XAuth, which is an extension on OAuth. It uses the same principles of request / access tokens and secrets, but allows you to exchange a username / password combination for a access token.
We use it like:
User logs in onto our iPhone app
iPhone creates OAuth request token request, plus sends username + password over HTTPS
Validate request (secrets etc., + username / password), generate request token, and exchange request token for access token. (This step is fully on the server, so the server does the exchanging).
Access token is returned to the user
iPhone app uses normal OAuth protocol + access token to communicate to server
Same way Twitter is doing it for apps that don't allow for an easy OAuth authentication page.
Eran Hammer-Lahav says,
The user should be in control of their
resources, but if this is just a case
of one provider spread over multiple
domains, I see no harm in skipping
granting access to a client which is
essentially owned by the same entity.
Take a look at the oauth2 client credentials flow.