I have an application that offers SSO log in through OAuth 2.0 for my customers.
So far, I am using Shared secret client credential, but I now want to support Private key client credentials, and am struggling on finding information on an important detail for the certificate approach:
What type of certificate should be used ?
Does the application have to generate a certificate per customer ?
Is a cloud provider (i.e. AWS ACM) public certificate enough for this kind of implementation ?
For information, one of the systems I have to integrate with runs on Azure. Here is a link to the docs about authentication with certificate credentials
Related
I have a client server scenario.
I have both thick client and a thin client (browser) which communicates with my server.
My thick client uses X-509 system certificate for client certificate authentication scenario and communicates with the server
Also this certificate is used for used to generate signed URL (with expiration time) for my thin client to communicate with my server which is used for integrity and authorization purpose. I also have a token based approach for authentication purpose in this case.
Now i want to complete move my authentication mechanism to OAuth based flow using client credentials or auth code based.
I understand that authentication and authorization can be moved to OAuth based communication. But how do i move my signing (digital signature) based use case to OAuth from certificate based ?
I don't think there is any other way than to use certificate based PKI mechanism for digital signing. Can the private and public keys be distributed other than the certificates ?
Best Regards,
Saurav
Can the private and public keys be distributed other than the certificates ?
You may generate key pair using openssl (command line - openssl.exe) or any cryptographic library or CSP of crypto device. Instead of distributing it, you may have a piece of software which user may use at his end to generate public key and private key and share public key if required and store private key securely. But question remains how user would store private key securely and there comes certificate storage formats like PFX which is password protected (encrypted using password you provide) or storing private key in smartcard or usb token which are cryptographic devices. You may program these devices to generate our own keys and not necessarily store certificate issued by CA.
For browser based access to user's private key, you may need to use browser extension.
Refer to this SO answer for accessing user's keys from browser for authentication.
I have integrated wso2is-5.5.0 and weblogic12c(OWSM) with our product for OAuth2 implementation.
Imported wso2carbon certificate in weblogic12c(OWSM) key store for token decryption.
Facing same issue, can anyone please provide information about following question:
How wso2is-5.5.0 encrypt OAuth token? From which key? what is key location path?
I am not able to see correct kid values in our OAuth token generated form wso2is-5.5.0. Because key alias is wso2carbon and token has kid NTAxZmMxNDMyZDg3MTU1ZGM0MzEzODJhZWI4NDNlZDU1OGFkNjFiMQ.
Do I have to use custom certificate and key alias? Can you please provide document/link to follow steps?
Is there any way to use custom OAuth Client Key and OAuth Client Secret?
Answering your questions,
If you have enabled the JWT encryption, it is encrypted with the key you have configured in the service provider.
In the IS implementation thumbprint of the certificate is used for kid value.
To encrypt the JWT, you always have to upload the public cert to the service provider config. Otherwise you can't encrypt the JWT. So always you are using a custom certificate. Refer this doc to get more details on how to add cert to service provider config.
This is possible if you are adding the service provider from the admin service. Refer to this doc for more information.
Apart from the above questions, if you are signing the JWT, it is signed using the server private key (for super tenant. In case of tenant, tenant private key is used). Default keystore wso2carbon.jks is location in <IS_HOME>/repository/resources/security. You must change this keystore when you do the deployment in production. Refer this and this to change the keystore.
Hope all of your questions are answered.
Using VS2017 I created a new MVC application. Authentication was set to work/school accounts using on-prem ADFS server. The VS wizard asked for ADFS metadata and relying party's URL information, which I entered. On the ADFS side I configured a WS-Federation trust. The application is authenticating/working just fine.
Referencing this blog...
Mega Takeaway: What this also means is that every SaaS application must have a copy of the public portion of your ADFS token signing certificate.
...my question is how is the relying party able to verify the digital signature of the SAML token when it was no information about the token signing certificate? Or does it? How?
The ADFS metadata contains all the public keys.
The built-in code extracts the metadata and get the information from there.
I am new to Hashicorp Vault. I was hoping to secure my client id and secret for an OAuth2 Password Flow using Hashicorp Vault. Each time my backend REST API is called, it requires the client id and secret, as well as the user credentials of username and password. How would I do this in a secure way and only let my app pass this without disclosing this in my javascript client?
Thanks.
John
If I read your question correctly, you have a Javascript application that calls your own (REST) backend service. That call is secured using a client id, client secret, username ánd password. That raises a couple of issues:
client id and secret, as well as the user credentials of username and password
That seems like the wrong approach to take: an OAuth-secured resource (your REST backend service) should not require a username and password. Logging in the user is done in the authorization server.
Try starting with reading the OAuth2-spec (RFC 6749) or the DigitalOcean tutorial for a comprehensive overview.
How would I do this in a secure way and only let my app pass this without disclosing this in my javascript client?
You can't: client secrets cannot be protected in a client-controlled application because an evil client can reverse-engineer your application (or read your javascript). What you have is called a "public client", i.e. a client that cannot keep its secret confidential. In this case, you don't use client secrets. Try starting with this question or the introduction to oauth2 client types.
I have an application for Windows in C# and i wanted to connect to Google calendar. In the tutorials and documentation example here they require some client secret which is to be generated when requesting client ID for a service account. But it's not. However I can see the public key fingerprints and I installed a certificate that was generated when I requested the client ID.
My guess is that their documentation is outdated. Can anyone give me a tutorial/reference or explain how this is should work now?
Thanks
Last time I used Google Calendar API you did not need a Client Secret for Oauth Service Account authorization. You just need Application ID, private key and the service account email address if I am right. I used it with java, but here is an example for .NET if it can help you.
https://developers.google.com/api-client-library/dotnet/guide/aaa_oauth#service_account
According to RFC 6749 (OAuth 2.0), the token endpoint of OAuth 2.0 authorization server requires client authentication in the following cases.
The client type of the client application is confidential.
The client type of the client application is public but the client application has been issued client credentials (client_id + client_secret).
To put it the other way around, client authentication is not required (so client_secret is not needed) when the client type of the client application is public and the client application has not been issued client credentials.
By definition, a public client cannot keep its client credentials confidential. Therefore, in general, implementations of OAuth 2.0 authorization servers won't issue a client secret for public client applications. It sounds that Google's implementation behaves so, too.
Probably, the reason Google did not issue a client secret to your application was that the client configuration you choiced had made your client application a public client.
The public key fingerprint is a different matter. RFC 6749 (OAuth 2.0) does not mention anything about public keys. Instead, I guess it may be related to OpenID Connect Core 1.0, OpenID Connect Dynamic Client Registration 1.0 (especially token_endpoint_auth_method), or Assertion Framework for OAuth 2.0 Client Authentication and Authorization Grants. You have to read Google's document to know what the public key fingerprint is for.