I am planning to use Google as my OAuth2 Authorization server. How to configure the roles for the user, in case we are using Google,FB,Github as our Auth server? My Spring Security expects the roles/authorities to allow/deny access to the protected resource.
Related
I have a client application accessing my server resources protected by authorization code grant type. Now the client application need another resource access which is protected by client credentials.
Since they already have client credentials for authorization code grant type, they want to use the same credentials for client credentials grant type.
Is it recommended to use the same client credentials for both authorization code and client credentials grant type? If yes/no, why?
You can use the same clientid and secret for both flows and that is something that you can enable in many token providers.
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 implemented OpenIddict with ASP.NET Identity as a separate auth server and I use the client credentials and password flows. I also have a web api project as the resource server.
The resource server is deployed in IIS and needs to authenticate domain users as well as end users. All controllers have the [Authorize] attribute and the actions have a custom authentication filter inheriting from ActionFilterAttribute with which I check for permissions against the db. The resource server has integrated windows authentication.
Currently at this stage of the development I cannot use ADFS or AAD.
Domain users access the resource server using a Winforms app in which they pass their network credentials. End users have websites and native apps and will/should use password flow to get an access token.
So, my question is:
Should I have an endpoint with [Authorize] in the auth server with which the domain users can authenticate with? In this case I would also need to use integrated windows authentication (which I'd rather like to avoid).
And once the domain user is authenticated, should I use the client credentials flow to acquire an access token? Domain users do not need to be saved in ASP.NET Identity. End users will use password flow.
Is this the correct way to handle both Windows Authenication and OpenId?
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.
According the article oauth2 Simplified it could be 4 grant type for the oAuth server.
Authorization Code for apps running on a web server
Implicit for browser-based or mobile apps
Password for logging in with a username and password
Client credentials for application access
So the question is - should I have single endpoint for all of them and then choose which is used according the query string provided, or it will be better to implement single endpoint per each grant type?
From the OAuth2 specs:
Protocol Endpoints
The authorization process utilizes two authorization server
endpoints (HTTP resources):
o Authorization endpoint - used by the client to obtain
authorization from the resource owner via user-agent redirection.
o Token endpoint - used by the client to exchange an authorization
grant for an access token, typically with client authentication.
As well as one client endpoint:
o Redirection endpoint - used by the authorization server to
return
responses containing authorization credentials to the client via
the resource owner user-agent.
Not every authorization grant type utilizes both endpoints.
Extension grant types MAY define additional endpoints as needed.
So the answer is: reuse the end points for multiple flows, but distinguish between the Authorization endpoint and the Token endpoint.