We are using WSO2 IS v5.4.1
We want to authenticate users based on external user data store.
The desired steps:
User logins via Oauth to WSO2 IS with username and password
The login request is forwarded to an external service which authenticates the user by given username and password without authenticating by WSO2 IS default user store.
The service returns some kind of desired response to WSO2 and based on this response some kind of business logic is performed.
I saw that there are 2 options to achieve this:
Implement Custom Local Authenticator
Implement Custom Federated Authenticator
What the is the correct approach?
Thanks,
By the definition,
Local authenticators are to authenticate the user with a local user store. Presumably using username and password. You can use inbuilt login page to ask user's credentials and validate it against the local user stores.
Federated authenticators are to authenticate with 3rd party identity providers. Like Google or Facebook. In this case you won't ask user's credentials directly instead you'll redirect the user to 3rd party login page and after authentication 3rd party IDP will send the result.
By understanding the facts that you have provided, it seems you need a local authenticator where you can ask the user's credentials directly from them and authenticate against the user store.
PS: If you can directly communicate with the user store (Without using any API) and it's a OOTB supported user store (LDAP or JDBC), you can directly plug in that as a secondary user store (Or even as the primary user store) and authenticate against it without using any customization.
Related
Our OAuth client application is built with Spring (through JHipster). The OAuth provider only serves the authentication functionality, but not the authorization functionality. Ideally, we should only allow a small group of people to access our OAuth client application, but not all those users who can sign in to the OAuth provider.
A solution I can think of at this moment is to create a custom user role to control the access in the OAuth client application. That, however, only can be done after the user's first sign-in when the user account data is created in the application.
Any better solutions?
Ideally you would apply user access control before creating user account data is created in the application. You could do so by providing an application specific scope or claim in the token that is generated for your application (aka. Client). Upon receiving the token, the application would check for the required attribute in the token before allowing access.
I would like users to register an account on my site via OAuth Spotify. I have the following scheme:
User authenticates via Spotify
Spotify ID and Mail are returned
An account will be created on the website (saved to the database)
The user can log in with his Spotify to access that account
The problem I foresee here is that someone can spoof the authentication by copying the ID of another user and it's mail, am I right? If so, what would be a better way to let an user create an account using Spotify Authentication? Let the user set a password? That seems user unfriendly to me.
So, how can I achieve this?
You can use the access token acquired through OAuth to find the associated username. You can use this as the basis for your accounts instead of a username or password on your own site. The process would be something like:
The User authenticates via Spotify
The Spotify OAuth callback returns a authorization code
You use the authorization code to get an access and refresh token for the user
You use the access token to access the associated User ID and use this as the unique ID for the accounts on your site.
Save an account with the Spotify user ID to your site's database
The user can log in again with Spotify to access their account (it will streamline the process by skipping the Spotify OAuth view, if they have previously approved your site, and are logged into Spotify in their browser)
Since your application will only retrieve the User ID from someone's valid access token, and the only way your application will receive that is if they log in through the Spotify OAuth flow, each account on your site will be linked to a valid, unique, Spotify user.
While looking into this, there are security considerations about using OAuth alone to authenticate users. I would look at this post on Security Stack Exchange and decide based on what level of security is needed for your site.
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.
I am trying a POC with WSO2 API manager and Identity server. The application users are registered to the user store on the identity server. An API is exposed on the API manager that will be used by the application. The goal is to authenticate the users accessing the application using the oauth resource owner password credentials. The user credentials are in the user store on the identity server.I created a new tenant for this.
I configured SSO for the API manager by using this documentation. so that the users are authenticated against the identity server user store.
Tried to generate a token to access the API exposed on the API manager. I was able to retrieve the token client credentials grant type but not for the resource owner password grant type.
Appreciate any help here.
I do not think, you need SSO here. SSO is needed with APIM and WSO2IS, if users need to login to the API store/publisher/APIM management console. I hope you are talking about end users.. Then end users are may not need to login to the APIM. They just need to login your custom applications and application would call the APIs in the APIM.
But, say user need to login to custom applications using SSO, then you can configure SSO between WSO2IS and custom applications. Please refer here. Once user login to the application, application can exchange a end user's SAML2 Assertion with access token by using APIM. Then application can access the APIs in APIM using access token behalf of the user. You can refer this for more details
Also, if you are just trying to use OAuth just for authentication, You may need to use openid-connect. (just to login to custom application)
How do I secure my API when I want an app to be able to retrieve app-specific information without a user logged in and when I have an OAuth provider for another section of my API? Can I use the client app's OAuth credentials to hit the API without a user logged in?
I have create an OAuth provider and client using doorkeeper following railscasts 353. I can successfully authenticate a user to my provider app and make requests on behalf of the user to my provider API.
However, a portion of the API is user independent, meaning that the information returned from the API is not specific for a user and therefore a user should not have to be logged in. For example, assume an ecommerce site and items and prices are stored on the provider for multiple clients. I want a client app to be able to securely retrieve the items/prices associated the retrieving app without a user having to be logged in. So if you went to example.com the items would be displayed even if a user is logged in via OAuth.
I have only be able to retrieve this information via OAuth when a user has logged in through OAuth (creating an access_token). Is there a way to use OAuth without having a user present (I've been trying to read about 2-legged OAuth and if that is an appropriate solution)? Or do I need to use Api keys (or Http Basic Auth) for the application to retrieve the application specific data?
If OAuth is not the right solution because I do not have a user present, could/should I use HTTP Basic Auth over SSL and use the client site's OAuth secret key as the API key for the basic auth username?
If you need to authenticate your client apps in you API (without requiring a user specifically) use the Client Credentials flow