IdentityServer allows you to register a ISigningCredentialStore and a IValidationKeysStore, which in turn enables dynamic loading of certificates from, for example, Azure Key Vault because the certificate store is called each time which handles lifetime, caching, updating etc.
What is the equivalent to achieve the same in OpenIddict?
Related
I am currently working on a few services that uses keyvault, authenticating with ClientCertificateCredential / Registered Apps. These are running on-premise.
Looking into using Azure App Configuration in a similar way, combined with keyvault. So a couple of questions arises:
Can i authorize against App Configuration the same way as with KeyVault, using ClientCertificateCredential ? If yes, how ?
If not, another option is to use a connection string against App Config. However, this is a secret, and should be stored in keyvault (absolutely not in appsettings.json). That means I have to access keyvault before setting up App Config. Is there a clean way to do this ?
Or, perhaps there is something else I should consider.
• Yes, you can surely authorize against App configuration as you do against key vault to retrieve client secrets, connection strings and other sensitive information with the help of managed identities. Managed identities create a service principal for the said application when enabled depending on the user to be assigned to that application or directly to the application itself as a system assigned managed identity that is created for the lifetime of that application.
By leveraging managed identity, it eliminates the need for an access token that contains secrets. Your code can access the App Configuration store using only the service endpoint. You can embed this URL in your code directly without exposing any secret.
• For more information on configuring managed identity to access the application configuration without exposing or leveraging any type of access token, please refer to the documentation link below for more details: -
https://learn.microsoft.com/en-us/azure/azure-app-configuration/howto-integrate-azure-managed-service-identity?tabs=core5x
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 am trying to limit access to the secrets/certificates so that only certain users can view/access some of them.
How do I go about doing that?
limit access to the secrets/certificates so that only certain users can view/access some of them.
In short, it's impossible.
You can limit only certain user to access all the secrets or certificates, other than access some of the secrets.
Simply find the Azure Key Vault in the Azure portal UI, click Access policies under settings, and add a new access policy. You can define fine-grained permissions for accessing Key, Secret, and Certificates (which Azure Key Vault can also store, by the way). However, when you allow some user to access your key vault secret, they will access all the secrets in azure Key vault.
For more details, you could refer to this article.
Currently, I am getting an API key from the server after logging in and using it to make http requests. I currently store the API key in the iPhone app's database. However, I've heard that I should store it in a keychain from a colleague. So, I searched on Stackoverflow and seen questions regarding this. It seems this isn't really a secure way of storing API keys at all.
Secure keys in iOS App scenario, is it safe?
In iOS, how can I store a secret "key" that will allow me to communicate with my server?
I don't know a way to stop hackers from reverse engineering to get the API key from the iOS app. A user on StackOverflow basically said it will only overcomplicate things for little to no benefits.
I need to find the post, but someone recommended to just make sure you're making a secure API request (SSL certificate) and you have a way to remove the API key if someone is hacked.
As already pointed out by #jake you should use a token tied up only to the user instead of an Api Key for all users, but other enhancements can be done for further protect your App when doing the http requests.
The user token can be a signed JWT token and then you can enhance the security of the communication between your server and the App with Certificate Pinning in order to protect against Man in the Middle Attacks.
Other techniques like the use of OAUTH2 and hiding secrets can be used to enhance the security of your App and you can read more about it here.
Keep in mind that Certificate Pinning can be bypassed by hooking frameworks such as Xposed that contain modules specific to bypass the pinning, but still another layer of security that you should not discard once it will increase the effort necessary to hack your App on the device and will protect your App against Man in the Middle Attacks.
For ultimately security between your App and the back-end you should use an App integrity attestation service, that will guarantee at run-time that your App was not tampered or is not running in a rooted device by using an SDK integrated in you App and a service running in the cloud.
On successful attestation of the App integrity a JWT token is issued and signed with a secret that only the back-end of your App and the attestation service in the cloud are aware and on failure the JWT is signed with a fake secret that the App back-end does not know, allowing this way for the App back-end to only serve requests when it can verify the signature in the JWT token and refuse them when it fails the verification.
Once the secret used by the cloud attestation service is not known by the App it is not possible to reverse engineer it at run-time even when the App is tampered, running in a rooted device or communicating over a connection that is being the target of a Man in the Middle Attack.
You can find such a service in Approov that have SDKs for several platforms, including IOS. The integration will also need a small check in the App back-end code to verify the JWT token in order the back-end can protect itself against fraudulent use.
JWT Token
Token Based Authentication
JSON Web Tokens are an open, industry standard RFC 7519 method for representing claims securely between two parties.
Certificate Pinning
Pinning is the process of associating a host with their expected X509 certificate or public key. Once a certificate or public key is known or seen for a host, the certificate or public key is associated or 'pinned' to the host. If more than one certificate or public key is acceptable, then the program holds a pinset (taking from Jon Larimer and Kenny Root Google I/O talk). In this case, the advertised identity must match one of the elements in the pinset.
OAUTH2
The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf. This
specification replaces and obsoletes the OAuth 1.0 protocol described
in RFC 5849.
Disclaimer: I work at Approov.
A more secure mechanism would be to return an authentication token on login. This authentication token should be unique to the user. If you have proper authorization and security mechanisms on the backend (to mitigate DDOS attacks, injection attacks, users accessing other user’s data, etc) then who cares if they get their authorization token from the keychain or wherever it is stored? Since the authentication token is tied to their account you could just invalidate the token so it stops working if the user is malicious. And you could even disable their account altogether if you have the right mechanisms in place on the backend.
Many of the security mechanisms can be automated on the backend. Platforms like AWS can easily be configured to automatically disable accounts that are doing certain malicious calls to your backend.
I want to secure my API Proxy created in Azure API Management using OAuth 2.0.
I want to use Azure Active Directory for OAuth.
As per MS documentation, I have to manually create an Application in Azure AD and copy that CLIENT_ID and KEY into developer portal to generate OAuth Tokens. But this works only for developer portal to get JWT tokens.
Every time a new developer comes and registers a developer application on my developer portal, a pair of keys (Primary key & Secondary Key) are generated.
Can I use these keys to authenticate and generate JWT tokens.
Also I want this process to be automated, so that I do not have to do anything manually in AAD after developer sign-up and subscription.
I have also tried to visually represent the scenario I want to achieve:
The pictorial representation of my requirement