I am using in-memory DB for storing user details in WSO2 Identity server. I create couple of users via UI and now I want to authenticate those user using some external application.
Is there any available WSO2 service which takes User credentials and authenticate based on the details provided? I saw few articles where they mainly talking about User Stores. But there, I think, they directly connect to DB to compare the credentials.
There are multiple ways to authenticate a user from Identity Server. Easiest way is that you can call the admin service (SOAP service) for authentication (RemoteUserStoreManagerService/authenticate). Or you can create a OAuth application inside the IS and use resource owner grant type to pass the credentials and authenticate.
You can find admin service related information from here [1] and password grant related information from here [2]
Is there any available WSO2 service which takes User credentials and
authenticate based on the details provided?
I believe we've misused the Token API service ( /token with password OAuth profile) to request an OAuth code and the WSO2IS effectviely validates the user's credentials.
I suggest your application would stick to some authentication and authorization standards supported by the WSO2IS, such as OAuth 2.0 or SAML.
Related
I am trying to use client credentials grant for a back-end service using Keycloak as an identity broker for Azure AD. I also need to store access token from external IdP in Keycloak to retrieve group information from MS Graph API. I have this use case working for a confidential client using authorization code flow but I can't get it to work with client credentials grant.
I have created a "confidential" client in Keycloak with "Service Accounts Enabled" enabled. I have a also created an application in Azure AD with client credentials grant enabled and created a external Identity Provider in Keycloak.
I get the access token from Keycloak after authenticating using client_id and client_secret but when I try to retrieve external IdP access token from Keycloak endpoint, I get an error message that says, "User [GUID] is not associated with identity provider". I'd appreciate any suggestions or feedback.
Thank you Sventorben Posting your suggestions as answer to help other community members.
Though is grant on client credential from both side Azure AD and Keycloak it is not possible to store the access token from Azure AD in Keycloak and later retrieve it from Keycloak to make requests to Graph API.
The client credentials grant type is used by clients to obtain an access token. This is totally outside of the context of a user. Keycloak will not forward or redirect requests to AD in this case. Hence, there will never be an AD token. If you need client credentials grant issuing a token from AD, you will need to make the request to AD directly.
From the below document it seems Keyclock is broker it should never send the original access token which is receive from Azure AD to access the Graph API. Only you can read the token using enable StoredTokens Readable switch.
Refence: https://wjw465150.gitbooks.io/keycloakdocumentation/content/server_admin/topics/identity-broker/tokens.html
I need to get authenticated using OAuth2 client credentials as the grant type. The app would need to call the OAuth2 server with only the client id and client secret, get authenticated and receive an access token back, then the app can use the access token to obtain the application's data. There is no regular user involved and the data belongs to the app. This is the same concept as your application connects to the database with a user name and user password belong to the application. The user uses the application without any knowledge of backend database accesses.
There are so many OAuth2 servers that support "code" grant type such as Google, Facebook, Github, but I have not found anyone that supports client credentials. Google asks me to set a service account, it is not the same as client credentials. Does anyone know an OAuth2 server that I use to test my client credential grant code? Thanks.
Keycloak has support for client credentials as authentication for the token endpoint.
https://www.keycloak.org/docs/latest/authorization_services/#_authentication_methods
In the past, I have had 2 APIs, both secured with Azure AD. The first API would take the access token and request another access token for the second API with the following param: requested_token_use=on_behalf_of
Info source: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-on-behalf-of-flow
However, this is due to both APIs being on Azure AD. Controlled in the same directory.
If the first API was Azure AD and the second was auth0, how would the second API get an access token without the user being able to login to a authorization screen?
In that case you can use Password Grant Flow or Client Credentials Flow.
You can read more about service to service authentication on Microsoft or Google pages.
Does this give you everything you had with on behalf flow? No. With on behalf flow you had token with user's claims for both systems. This way you access service B with service A credentials and if you have fine-grained per user permissions you need to implement logic in service A.
I am currently being tasked with writing an RESTful API that we are going to release to our clients. I plan to use Web API 2 with OWIN middleware. The applications that will be accessing this can range anywhere from a Console app with no additional user authentication to full blow web applications that will involve user login and authentication.
One other requirement is that we need not only provide user authentication to control what data we will return, we also need to authenticate that the application accessing our API is allowed by our organization. So this requires us to not only validate the application invoking our API's but also the many users logging in via that application.
The goal is to use a bearer token technology like OAuth 2. I am not very familiar with OAuth 2 but after looking it over I don't see a way to facilitate a two part authentication like this. Ideally we would like to issue a clientId and a clientPassword and they would pass this in along with the userid and userpassword and we would then pass a token back.
Is this something that anyone has tackled before using OAuth2 or is this a job for a custom auth solution?
What you describe sounds like fairly standard Oauth2.0 scenarios so you shouldn't need anything custom.
For the web apps you could use the Resource Owners Password Credentials Grant. Which is a standard flow.
This allows your Oauth client to pass in its client Id and client secret along with a user's Id and password to your Auth Server which can then validate both the user and the client before issuing a token in response.
But I would recommend using the Authorization Code Grant which is probably the best option for web applications and it involves both the client and the user being effectively authenticated.
For you console apps, or any apps which are not user specific, you can use the Client Credentials Grant. This allows the app to authenticate and to get a token without a user.
If you need your API to be aware of the client application, the only flow you can't really use is the Implicit Grant which doesn't authenticate the client.
I am a newbie to OAuth 2.0.
I have fairly read the OAuth 2.0 doc and I saw there are four types of methods for obtaining Authorization.
Types of obtaining authorization:
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
In my case, I have Client application, Resource owner, Resource server and Authorization server.
Resource server is a website where Resource owner registers with his/her credentials.
Client application is a third party website who registers into resource server and gets the Client application credentials for accessing it in future.
Authorization server checks the client credentials from client app and grants access token to the client app.
Let us consider, resource server as "www.serversite.com", authorization server as "www.authserver.com" and client application as "www.clientapp.com".
Flow:
Step 1: Also make an assumption that www.serversite.com as a payment gateway site and the client has to integrate "www.serversite.com" into "www.clientapp.com" for creating, executing and refunding payments.
Step 2: So the client "www.clientapp.com" creates an app in server "www.serversite.com" and gets API credentials.
Step 3: Using these API credentials, the client "www.clientapp.com" makes an access token request to the auth server "www.authserver.com".
Step 4: If the API credentials from client app are valid then the auth server grants an access token.
step 5: With this access token, client app request the resource server for further operations like creating payments as well as executing payments.
My questions:
I am using ASP.NET Web API for authorization server and using OWIN.OAuth for generating access token, refresh token, authorization and all the stuffs needed to authorize the client app.
But, in this link (OWIN OAuth 2.0 Authorization Server), I found that, the web api authorize the client app using "Resource Owner Password Credentials Grant" and the sample provided for implementing Owin.OAuth in web api is great, but I have lot of confusions roaming in my mind.
Which way of obtaining authorization is suitable for my process?
(Client Credentials flow or Resource Owner Password Credentials flow)
How to implement Client Credentials Grant type using ASP.NET Web
API(OWIN OAuth)?
Also provide some samples or links that may be helpful for me?
Thanks in advance.
Theres an example of how to get started on the asp.net website, specifically here:
http://www.asp.net/aspnet/overview/owin-and-katana/owin-oauth-20-authorization-server
I quote:
private Task GrantClientCredentails(OAuthGrantClientCredentialsContext context)
{
var identity = new ClaimsIdentity(new GenericIdentity(
context.ClientId, OAuthDefaults.AuthenticationType),
context.Scope.Select(x => new Claim("urn:oauth:scope", x))
);
context.Validated(identity);
return Task.FromResult(0);
}
Obviously you will need to go ahead and verify the actual client id / secret exist perhaps in a local database sometwhere before you go ahead and set the context to validated.
In terms of deciding which flow to use, you need to ask yourself, if the application is requesting access to your APIs on behalf of an actual user, then you need to use Resource Owner, however if the application itself needs access then Client Credentials is the way to go.
Generally speaking though, most implementations use Authorisation Code Flow, so if you can form a security stand point, get the users redirected to a page you host to take their credentials, opposed to sending them over the wire via Resource Owner Flow.