I'm working on a OAuth2 server project. Can I use domain name for generating client_id ?
Ex: For instance if Google registering an app in my server, then the client_id will be google.com
Am i allowed to use dots in client_id? Is it wise to use domain as client_id ? what are the drawbacks?
According to Specification
The authorization server issues the registered client a client
identifier -- a unique string representing the registration
information provided by the client. The client identifier is not a
secret; it is exposed to the resource owner and MUST NOT be used
alone for client authentication. The client identifier is unique to
the authorization server.
The client identifier string size is left undefined by this
specification. The client should avoid making assumptions about the
identifier size. The authorization server SHOULD document the size
of any identifier it issues.
Related
I'm building an API gateway using Spring Cloud Gateway and I'd like to secure it.
In our current architecture the API gateway will be hidden behind a portal which authenticates using a client certificate (issued for a system user) and sends the name of the real user calling the service in an HTTP header.
I'm looking for a way to configure Spring Security to both verify the certificate (so that nobody else can call the GW) but at the same time construct the principal from the provided header (after the cert check succeeds).
If I use the standard x509 from Spring Security (with provided subjectPrincipalRegex) the user service receives just the matching part as the user ID so I can construct the Principal from the username in the cert (which is still the same).
I.e. I'm looking for something like this
No client cert or invalid client cert => anonymous user (still can have access to some routes)
Valid certificate => obtain UserDetails based on the HTTP header (which can still result in user not found in the DB, i.e. anonymous access).
Note: Since Spring Cloud Gateway is reactive I'm looking for solution applicable to Spring WebFlux Security but I believe that the concepts are the same as in "standard non-WebFlux" security
I'm writing an application that uses keycloak as its user authentication service. I have normal users, who log in to keycloak from the frontend (web browsers), and service users, who log in from the backend (PHP on IIS). However, when I log in from the backend, keycloak uses HS256 as its signature algorithm for the access token, and thus rejects it for further communication because RS256 is set in the realm and client settings. To get around this issue, I would like to "pretend to be the frontend" to get RS256 signed access tokens for my service users.
For security reasons, I cannot give the HS256 key to the application server, as it's symmetrical and too many people can access the server's code.
I am currently debugging the issue using the same user/pw/client id/grant type both on the frontend and the backend, so that cannot be the issue.
So far I have tried these with no luck:
copying the user agent
copying every single HTTP header (Host, Accept, Content-Type, User-Agent, Accept-Encoding, Connection, even Content-Length is the same as the form data is the same)
double checking if the keycloak login is successful or not - it is, it's just that it uses the wrong signature algorithm
So how does keycloak determine which algorithm to sign tokens with? If it's different from version to version, where should I look in keycloak's code for the answer?
EDIT: clarification of the flow of login and reasons why backend handles it.
If a user logs in, this is what happens:
client --[login data]--> keycloak server
keycloak server --[access and refresh token with direct token granting]--> client
client --[access token]--> app server
(app server validates access token)
app server --[data]--> client
But in some occasions the fifth step's data is the list of users that exist in my realm. The problem with this is that keycloak requires one to have the view-users role to list users, which only exists in the master realm, so I cannot use the logged in user's token to retrieve it.
For this case, I created a special service user in the master realm that has the view-users role, and gets the data like this:
client --[asks for list of users]--> app server
app server --[login data of service user]--> keycloak server
keycloak server --[access token with direct granting]-->app server
app server --[access token]--> keycloak server's get user list API endpoint
(app server filters detailed user data to just a list of usernames)
app server --[list of users]--> client
This makes the the list of usernames effectively public, but all other data remains hidden from the clients - and for security/privacy reasons, I want to keep it this way, so I can't just put the service user's login data in a JS variable on the frontend.
In the latter list, step 4 is the one that fails, as step 3 returns a HS256 signed access token. In the former list, step 2 correctly returns an RS256 signed access token.
Thank you for the clarification. If I may, I will answer your question maybe differently than expected. While you focus on the token signature algorithm, I think there are either mistakes within your OAuth2 flows regarding their usage, or you are facing some misunderstanding.
The fact that both the backend and frontend use "Direct Access Granting" which refers to the OAuth2 flow Resources Owner Credentials Grant is either a false claim or is a mistake in your architecture.
As stated by Keycloak's own documentation (but also slightly differently in official OAuth.2 references):
Resource Owner Password Credentials Grant (Direct Access Grants) ... is used by REST clients that want to obtain a token on behalf of a
user. It is one HTTP POST request that contains the credentials of the
user as well as the id of the client and the client’s secret (if it is
a confidential client). The user’s credentials are sent within form
parameters. The HTTP response contains identity, access, and refresh
tokens.
As far as I can see the application(s) and use case(s) you've described do NOT need this flow.
My proposal
Instead what I'd have seen in your case for flow (1) is Authorization Code flow ...
assuming that "Client" refers to normal users in Browser (redirected to Keycloak auth. from your front app)
and assuming you do not actually need the id and access tokens back in your client, unless you have a valid reasonable reason. As the flows allowing that are considered legacy/deprecated and no more recommended. In this case, we would be speaking of Implicit Flow (and Password Grant flow is also discouraged now).
So I think that the presented exchange (first sequence with points 1 to 5 in your post) is invalid at some point.
For the second flow (backend -> list users), I'd propose two modifications:
Allow users to poll the front end application for the list of users and in turn the front-end will ask the backend to return it. The backend having a service account to a client with view-roles will be able to get the required data:
Client (logged) --> Request list.users to FRONTEND app --> Get list.users from BACKEND app
(<--> Keycloak Server)
<----------------------------------------- Return data.
Use Client Credentials Grant (flow) for Backend <> Keycloak exchanges for this use case. The app will have a service account to which you can assign specific scopes+roles. It will not work on-behalf of any user (even though you could retrieve the original requester another way!) but will do its work in a perfectly safe manner and kept simple. You can even define a specific Client for these exchanges that would be bearer-only.
After all if you go that way you don't have to worry about tokens signature or anything like that. This is handled automatically according to the scheme, flow and parties involved. I believe that by incorrectly making use of the flows you end up having to deal with tricky token issues. According to me that is the root cause and it will be more helpful than focusing on the signature problem. What do you think?
Did I miss something or am I completely wrong...?
You tell me.
I have an application registered in Azure AD which uses certificates. I am trying to write a script which would add a new certificate to the application. This can be used to add a new certificate when the existing certificate is going to expire.
I am trying to use AddKey function of Azure AD Graph API. The request body of this api as a parameter 'proof' which is a JWT assertion signed by the existing certificate of the application. The doc says the "aud" claim in JWT should be set to "AAD Graph SPN". Here what is meant by "AAD Graph SPN"?
I tried with a JWT where "aud" was set to "00000002-0000-0000-c000-000000000000". But I am getting the following error,
{
"odata.error": {
"code":"Authorization_RequestDenied",
"message":{
"lang":"en",
"value":"Insufficient privileges to complete the operation."
}
}
}
Any thoughts on this?
I am getting the access token to call the Azure AD Graph API via "Resource Owner Credentials Grant" flow . To get the access token i am using the client_id "1950a258-227b-4e31-a9cf-717495945fc2" (The Well Known Client ID for Azure PowerShell")
My script (For deployment purpose) does something like below,
i) Get the access token as described above and registers a new application in Azure AD with a initial certificate.
ii) When the initial certificate is about to expire it should add a new certificate to the created application.
According to the documentation, you must use a self-signed JWT token to access that API:
As part of the request validation for this service action, a proof of
possession of an existing key is verified before the action can be
performed. The proof is represented by a self-signed JWT token. The
requesting application needs to generate a self-signed JWT token with
the following requirements...
The "Resource Owner Credentials Grant" won't work here in this situation. Instead, use the "Client Credentials Grant":
https://learn.microsoft.com/en-us/azure/active-directory/develop/active-directory-protocols-oauth-service-to-service
The application you want to update should be the Client ID used to get this access token.
The other option is to update the application directly using an PATCH request on the Application Object:
https://msdn.microsoft.com/en-us/library/azure/ad/graph/api/entity-and-complex-type-reference#application-entity
Using this method, you should be able to update using the method you described above (user credentials and an external Client ID)
Let me know if this helps.
I was able to have my application act as a SP with the IDP SSOCIRCLE using the Spring Security SAML extension. My customer has the following requirements:
1. Have the assertion signed: The assertion sent from the IDP is signed and it is working fine.
2. Have the request/response signed: When using SSO Circle to generate the metadata file. I selected the option AuthnRequestsSigned to true. I uploaded my SP metadata to the SSO Circle IDP. The SP metadata had the following values as true: AuthnRequestsSigned & WantAssertionsSigned. When running the application neither my request nor the response I get are signed.
I am having issues to have the second requirement done. I am new to SAML and to Security in general. What am I missing here?
UPDATE
After taking into consideration Vladimir's comments. I changed my binding to HTTP-Post, so now I am sending the SAML Request with the signature shown.
I was able to send the request signed using my private key(not the one provided by the sample project) by doing the following:
Create a keystore, CSR, and a public key certificate using the keygen tool.
Update the Digital Signature section in my SP metadata file to have the new certificate
Remove the old SP metadata file from IDP SSOCIRCLE and add the new SP metadata file
Change spring configurations to have the JKSKeyManager to use the new keystore I created with the new alias and password.
What I need to do now is to have the IDP(SSOCIRCLE) send the response where
a. The response is signed
b. The assertion is signed
How can that be achieved? what changes do I need to do to handle that, given that
the signing of the response should be different than the signing of the assertion.
Thanks.
HTTP-Redirect binding requires that any ds:Signature element present on the SAML message itself is removed before sending of the message:
Any signature on the SAML protocol message, including the XML
element itself, MUST be removed. Note that if the content of the message
includes another signature, such as a signed SAML assertion, this
embedded signature is not removed. However, the length of such a message
after encoding essentially precludes using this mechanism. Thus
SAML protocol messages that contain signed content SHOULD NOT be
encoded using this mechanism. (saml2-bindings, 578-582, copy pasted from PDF)
At the same time HTTP-Redirect binding requires that a new digital signature is attached to the GET URL as parameter Signature.
This means that with HTTP-Redirect you cannot send message with Signature on message level, instead the signature is added to the URL. Therefore the whole message sent from Spring SAML to IDP is signed (check it from the data sent from the SP).
There is no standard way to force IDP to send the Response message signed on message level in addition to including signature in the assertion. In case you're using SSL/TLS the authenticity and non-repudiation of the message (characteristics of digital signatures) is provided by transport layer.
We are trying to connect to a custom Dynamics 365 Finance service operation but are struggling to authorize.
We've set up an app registration
Redirect_uri set to the dynamics url (root)
Enabled implicit grant (both for access tokens and ID tokens)
Single tenant
Assigned the "Dynamics ERP > CustomService.FullAccess" API permission
Assigned the "Dynamics ERP > Odata.FullAccess" API permission
Assigned "Dynamicd ERP > Connector.FullAccess" API permission + granted admin consent for entire AD
Created a secret
We've added the Application (client ID) within the Dynamics 365 environment with a user which has System Administrator role
We can successfully retrieve access tokens both via Postman and .NET (Microsoft.IdentityModel.Clients.ActiveDirectory)
we tried to reach both https://xxxxxxdevaossoap.cloudax.dynamics.com &https://xxxxxxdevaos.cloudax.dynamics.com
Yet when we call custom services, we get a 401 UnAuthorized
A call to Odata also fails for the same reason.
Verify resource in your request for OAuth token (and verify token at https://jwt.io for aud (Audience) field).
It should be same as your primary url without / at the end (like https://d365fo-10-12345678baef10230aos.cloudax.dynamics.com).
Also verify that Azure Active Directory applications (mi=SysAADClientTable) Client Id is equal to appid field in the token (and without any special characters).
You can always inspect Windows Event Log Microsoft-Dynamics-AX-WebApi/Operational
There is good information like this:
Source: Microsoft-Dynamics-AX-WebApi
Category: WebApiOwinConfigurationMissingError
Level: Error
Description: Web API Owin Authentication Configuration Missing Error
infoMessage: Can read the token but failed validating token with exception
'IDX10214: Audience validation failed.
Audiences: 'https://d365fo-10-12345678baef10230aos.cloudax.dynamics.com/'.
Did not match: validationParameters.
ValidAudience: 'null' or validationParameters.ValidAudiences:
'https://d365fo-10-12345678baef10230aos.cloudax.dynamics.com,
00000015-0000-0000-c000-000000000000,
Microsoft.ERP''