there is application that is deployed on openAM. for that particular application I have url, user Name and password how do i get token from that?
Unfortunately your description is very vague, but OpenAM offers many ways to authenticate a user; Distribute Auth (GUI), GUI Login, OpenAM Auth API, REST API ...
Related
Docusign rest api examples works using the manual login to docusign. The user has to enter the username and password to continue using the api's, I am looking for the method use api based on api credentials from backend config for better user experience. Can someone help on this whether we can achieve this
You can use JWT instead of Auth Code Grant. JWT Tokens do not require user to login and it is useful for back-end processes and other programs that do not have UI for user to login.
I have a requirement to retrieve the Auth Code from SalesForce API. I have created the scenario in Postman as below.
Configuring the new Token using the below parameters
Once I press "Get New Access Token", Postman opens a popup and asks to type the Username and Password in the login prompt. It shows the login page to SalesForce.
Once login success, Postman asks to use the token and it will be added here(See below image)
Then I hit the endpoint with the JSON body as a POST request.
I need to recreate this scenario in NodeJS in order to work the whole process as a single process bypassing all the login prompts.
I am using the below method to initiate this task in order to get the Token. However, the resources I found didn't match my requirement.
As the first step, I used salesforce-oauth2 npm package as below.
oauth2 = require('salesforce-oauth2');
var callbackUrl = "https://test.salesforce.com/services/oauth2/success",
consumerKey = "3MVG9sLbBx**********************2Qi.v***Vlhg3",
consumerSecret = "3MV**bBx**********************2Qi.v***Vlhg3";
var uri = oauth2.getAuthorizationUrl({
redirect_uri: callbackUrl,
client_id: consumerKey,
scope: 'api', // 'id api web refresh_token'
// You can change loginUrl to connect to sandbox or prerelease env.
//base_url: 'https://test.my.salesforce.com'
});
return response.redirect(uri);
When I debug I above code, it returns a URL pointing to the login page. I didn't want to pass this step since my requirement is to get the Auth-Code without opening any intermediate authentication popups.
How can I proceed with this? Any idea to program until the 3rd step to get the Auth Token from the SalesForce API?
Thanks in advance.
You tagged this salesforce-communities. It matters, is it really for community ("experience cloud") users or internals? Salesforce has lots of OAuth2 flows to chose from: https://help.salesforce.com/articleView?id=sf.remoteaccess_oauth_flows.htm&type=5
If you know the password and it's internal user (maybe real human, maybe you have some dedicated "Integration User") - you can work with Username-Password flow. There's no login page and no OAuth consent step. But
This flow doesn’t support scopes or refresh tokens. Experience Cloud
sites don’t support the OAuth 2.0 username-password flow.
You might be able to use JWT Flow. You need username (no password) and your Node app would be sending a message signed with certificate that you uploaded earlier to SF "connected app". You could even mark the users as preauthorised so there's no consent screen.
Other than that I think all OAuth2 flows available for community need a human to actually type the password in. You can pass login hint in the url to save them the username but pass they need to provide on SF login page before coming back to your app.
Dig a bit in help, happy to be proven wrong.
My problem is that I want to configure Openam so that it returns a JWT-token when I use The simplest user name / password authentication. By default, it returns tokenId. But in my case, I need only JWT-token. I am using this endpoint for authentication: http://openam-01.domain.com:8080/openam/json/authenticate.
Thx!
OpenAM only issues a JWT when you are using 'stateless' / client based SSO session. If you need a standardised JWT, then you need to configure OpenAM as OIDC provider.
You can configure OpenAM Security Token Service (STS) to exchange OpenAM authentication token to JWT.
In my Angular application (Frontend) the users can sign-in as following:
The user will fill-up a login-form (username or email / password).
The user will click on Login and that will hit this endpoint: http://localhost:8080/auth/realms/REALM_NAME/protocol/openid-connect/token
The user will have an answer in JWT format and will get his access_token (jwt token), refresh_token... etc.
Now this token will be used to access my backend APIs that will check the validity of the signature of this token against the JWKs_URI (with the encryption RSA256).
The question now is : how can I enable user registration in the same way, which means, I wish that the user can:
Fill up a registration form
Enter his email, password, password confirmation, more info (attributes maybe)
The user will then click on Register and it will hit an endpoint in Keycloak (/register maybe) which will return some answer about the success of this registration.
BTW: I don't want to use the user management API.
You can use Keycloak Admin REST API to register new users. Make sure to not expose it carelessly.
Regarding you question, related to the authentication, you can register a Keycloak OIDC client. OIDC offers a bunch of resources you can use.
If you register your application as a Keycloak client that uses OIDC direct grant. Basically "direct grant" implies you can get an access token with just a simple POST to /realms/{realm-name}/protocol/openid-connect/token.
The documentation about direct grants is scattered across the Keycloak documentation and some details can only be found in the OIDC RFCs; so I found you this page that ties everything together.
Careful again ! It might be obvious but don't turn you Angular app into a OIDC client otherwise hacker will steal your Keycloak client's credentials. Make sure to have your Angular app call some server, where you'll implement the necessary safety mechanism to block abusive use of your client (for instance using CAPTCHA).
I would like to give the users a possibility to login with some external oauth2 provider (facebook) in my app. The client's part is running on mobile device in a native app.
I am not sure which of the approaches below should I prefer ?
Should the client send the user's access token by facebook with each request ? At each request backend asks facebook to validate the access token. Based on the validation's result, backend performs authorization and return corresponding result to the client.
Should the backend ask facebook to validate the access token only at user logon, then issue its own access token, return the access token back to the client and client will use this access token at making requests to the server to avoid contacting facebook at each request ?
I have read some questions about how to implement the auth with facebook and most of the devs are using B, but I haven't seen any explanation why is it good/bad to use A ?
What I see as benefits of the solutions:
backend doesn't need to care about issuing, refreshing, validating access tokens since this is done only by facebook's authorization servers.
this solution seems to be more effective, since it does not require to connect to facebook at each request.
Security tokens issued by Facebook are signed with a digital signature. The API server only needs access to the public key to validate the signature. There's no need at all to contact Facebook after the user authenticates.
A reason to issue your own tokens after the user signed in with Facebook could be to add claims to the token. But obviously having your own authorization server comes at a cost. It's up to you to weigh the pros and cons.
If you do decide to have your own authorization server, make sure not to write your own! There are open source options like Thinktecture IdentityServer.
I will vote for option B and here is my explanation,
Your API must authorise the request every time with some auth token , which cannot be external provider token, in such case anyone with an access token (eg: other developers) of other provider can access your api, basically there is no auth here.
When your sever issue access token, it's easy to validate and when needed could be revoked easily (eg: on password reset)
While authenticating , your server has fully control over issuing access token , so the validation is made only once and doesn't have to do every time while calling the API.