Is there is an endpoint in openAM which I can use to retrieve the client secret from the OpenAM.
I'm using the OpenAM as the keymanager and I have used the below endpoint with parameters to create an application in OpenAM
http://localhost:8080/openam/frrest/oauth2/client/?_action=create
Now I need to retrieve back the client secret using client name as I don't store it in my application side. What is the endpoint I need to use for it? I couldn't find it in the OpenAM documentation.
If OpenAM is not allowing to retrieve the client secret with the Client Name, what is the best way to handle this use case?
Client secret is stored in hashed form that is irreversible in the OpenAM configuration store and cannot be retrieved.
Related
There's a helpful Microsoft doc that describes how to configure security for a daemon client application. This works ok but it means the client app must present a client id and client secret to the /token endpoint of AAD in order to obtain the OAuth2 access token.
This makes no use of managed identity and means I need to ensure the security of the client secret of the daemon app. If the client id and secret of this app were to fall into the wrong hands, there's nothing to prevent a bad actor obtaining an access token and calling the target service.
I realise that a certificate can be used instead of a client secret but my question is, can this be avoided through the use of the managed identity of the client daemon app?
I was reading an article about OAuth 2.0 with jwt tokens. Interesting part is when author describes client_secret, he says:
In a non-trivial implementation client ids and passwords will be securely stored in a database and retrievable through a separate API that clients applications access during deployment.
Now let's say I have a frontend app in angular and a backend app in spring with MySQL db.
My question is what author meant by the aforementioned quote. Is it, that
client (frontend app in this case) makes a call using client_id
and secret (nothing changes here), but backend is checking
provided "credentials" not by comparing with values stored in plain-text (in
application.properties in that case), but making a hash from received values and
comparing with hashed version in db ?
EDITED:
User john doe opens log in page. Provides credentials: username:john.doe and password:john1. Clicks sign in.
Angular-frontend intercepts request, and executes a method (f.e. obtainTokenForUser()) in order to get a short-period-valid jwt token for the user. For that reason angular-app sends an OAuth2.0-compliant request to the authorization server. Before sending contant AWS KMS to get its client_id and secret in order to attach to the request. In the end, the request from angular to auth server looks like: curl front-app-sp3:frnt4pP#<auth_server_ip_addr>:<auth_server_port>/oauth/token -d grant_type=password -d username=john.doe -d password=john1
Authorization server contacts AWS KMS for received client_id:front-app-sp3 and client_secret:frnt4pP. It finds the entry, passwords matches, validation correct. Auth server generates a JWT token valid f.e. 5 minutes. The token is signed by the server using AS_pr1v4t3 private key. Authorization server returns a token to angular app.
User is logged in. User requests a resource in the main app (in spring), thus angular adds an obtained token and sends the request to the "Main-web application".
Resource server in the "Main-web application" validates token. Token is correct and valid. Resource is returned.
I don't think that's what the author is referring to. He is talking about instead of having client_id and client_secret in your application.properties they are to be stored in a DB which your backend can access through a different API. I would argue that the client_id belongs more to the application.properties than the secret management service though. Your front-end (angular app in this case) should never have access to client-id or the secret. Your server which the angular app is connected to (through some REST services I imagine) should never have direct access to the secrets either, it should go through a separate secret management API. It's ok for your server to have the client_id in the application properties, but the secret should be stored in a very secure place.
This is an already implemented pattern though. Instead of having the secret values directly in the app.config / application.properties file you should have them in something like:
AWS Key Management Service
Azure Key Vault
These would allow you to store / update / retrieve and rotate your secrets.
I am using oAuth Model to access Podio API. I am able to generate the Access Token and Refresh Token using a pair of Client ID and Client Secret.
Later when i tried to authenticate using previously generated Access Token and Refresh Token with new pair of Client ID and Client Secret then getting Following Error Message:
{"{\"error_propagate\":false,\"error\":\"invalid_grant\",\"error_description\":\"Invalid refresh_token\",\"error_detail\":\"different_client_id\",\"request\":{\"url\":\"http://api.podio.com/oauth/token\",\"query_string\":\"\",\"method\":\"POST\"}}"}
When i tried to authenticate using same Pair of Client ID and Client secret that was originally used to generate the Access Token , it Works.
My Question is: Can we use different Client ID and Client Secret to authenticate through Access Tokens that were generated using different Client Id and Secret.
I hope i have clearly described my question.
No, access tokens are tied to a specific client and secret. Allowing access tokens to be used with other clients would be a security hole.
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 been trying to understand how OAuth2 works. At first I thought it was redundant to spend one extra step exchanging auth code + client secret for access token - why not have server return access token directly. For that I found this explanation.
Then what confuses me is, why does it need a clientId and a client secret, instead of just a secret? A secret which can both declare and prove itself. The client app then can simply pass it to server when it sends user there to authorize itself for accessing server resource.
Thanks!
Imagine the client signs the request with the secret and sends just the signature. How does the server know which secret to use? Presumably the server supports multiple consumers.
The client id is sent in the first part of the token dance to identify the client. This id is sent in an insecure way, in the URL. Even on the authz server end of this request the id may be exposed in an insecure way where the authz server redirects the user agent to the authorization page. So the client id is not meant to be secure, just to identify the client.
Only after receiving the authorization code (after user authorization), does the client then need to obtain the access token in a more secured way. This is where the client secret is used over TLS.
You can have the server return the access token directly. You need to request Implicit grant (response_type with the value token instead of code).
The authorization server returns the access token directly.
This type of grant is intended to be used for user-agent-based clients (e.g. single page web apps) that can’t keep a client secret or client id because all of the application code and storage is easily accessible. If your client can keep a secret, it is recommended that you use a more secure grant type.