I am building a CLI tool and want to create a new programmatic user for each end user.
I.e. Joe Bloggs signs up with username and password but also has a client_id and client_secret which can be used in the CLI.
Is it possible to create this kind of user in Auth0 and if so, how can I create it programmatically?
It looks like I can use this to create users via the API and do something like:
axios({
method: "POST",
baseUrl: "https://<tenant>.eu.auth0.com,
uri: "/api/v2/users",
body: {
"email": "john.doe#gmail.com",
"phone_number": "+199999999999999",
"user_metadata": {},
"blocked": false,
"email_verified": false,
"phone_verified": false,
"app_metadata": {},
"given_name": "John",
"family_name": "Doe",
"name": "John Doe",
"nickname": "Johnny",
"picture": "https://secure.gravatar.com/avatar/15626c5e0c749cb912f9d1ad48dba440?s=480&r=pg&d=https%3A%2F%2Fssl.gstatic.com%2Fs2%2Fprofiles%2Fimages%2Fsilhouette80.png",
"user_id": "abc",
"connection": "Initial-Connection",
"password": "secret",
"verify_email": false,
"username": "johndoe"
}
})
However, this appears to be for creating an end user: Create a new user for a given database or passwordless connection. as opposed to a CLI type user which can use a client_id / secret.
Does anybody know if I can create this kind of user in Auth0?
The client_id and client_secret that Auth0 issues to Applications (known in the API as /Clients) are for machine-to-machine interactions with Auth0, not with your own service. They allow a trusted backend service to manage the users within Auth0. Or, they allow an Application to initiate a user's OAuth2 authentication flow.
It sounds like you are looking to avoid an OAuth2 authentication flow and provide a static API key, not for Auth0, but for your own service. Auth0 may be overkill in this case, but you can roll your own solution using Auth0, or any user store. One suggestion is to manually generate an API token for new Auth0 users and store them in the users' app_metadata. When your CLI provides a username and API key to your backend service, your trusted backend service can use its Auth0 client_id and client_secret look up the user in Auth0 and confirm that the API key in the app_metadata matches.
Also note the existence of the Resource Owner Password Flow. It would allow your CLI to provide a username and password directly to Auth0 on behalf of your CLI user. The API token that you generate can be set as the user's password.
Related
When making a login request I can specify the following scopes: openid, profile, group, params
But I can't figure out how to specify my own custom scopes (e.g. MyApp.ReadWrite)
I've noticed that I can create + add users to groups and then request the group scope:
"groups": [
"MyApp.ReadWrite"
],
But doing it this way means that I can't use the access_token to authenticate because it contains the following "scope": "openid profile groups", and not what I really want "scope": "openid profile MyApp.ReadWrite"
I was under the impression that I should be authenticating users with the access_token and not the id_token. Is this mistaken? Should I just be using the id_token to authenticate users?
I'm using the https://accounts.google.com/o/oauth2/auth? endpoint to obtain the id_token.
The scopes are openid profile email.
The problem is that when I try to verify that id_token I get iss, azp, aud, sub, email, email_verified, iat, exp, jti. And as you can see there is no any profile info like given_name, family_name, picture.
The official doc says that it should contain profile info:
// These seven fields are only included when the user has granted the "profile" and
// "email" OAuth scopes to the application.
"email": "testuser#gmail.com",
"email_verified": "true",
"name" : "Test User",
"picture": "https://lh4.googleusercontent.com/-kYgzyAWpZzJ/ABCDEFGHI/AAAJKLMNOP/tIXL9Ir44LE/s99-c/photo.jpg",
"given_name": "Test",
"family_name": "User",
"locale": "en"
All permissions are granted.
UPDATE
So in case anyone ever needs it.
As Vladimir Serykh mentioned, to get profile info we need to hit the /userinfo endpoint. But this endpoint takes access_token as a Bearer token in a Authorization header, so you need obtain that too.
So basically we need to call the OAuth2 with the response_type='id_token token' query parameter. After that the responseUrl will contain access_token too.
Next you just need to call the https://openidconnect.googleapis.com/v1/userinfo endpoint with a Authorization header set to Bearer your_access_token. You will get a response wiht the profile info:
"sub": "user_id",
"name": "Name Lastname",
"given_name": "Name",
"family_name": "Lastname",
"picture": "pic_url",
"email": "example#gmail.com",
"email_verified": true,
"locale": "en"
Thank you again, Vladimir Serykh
It's not very clear how old the documentation is (by the link you provided) and is it relevant to your case.
I know that different Identity Providers can work slightly different. And I know cases when you should make a separate call with obtained ID token to /userinfo endpoint to get user info.
There is some different Google documentation for Google Identity Platform.
It has description of ID tokens.
https://developers.google.com/identity/protocols/OpenIDConnect#obtainuserinfo
Google ID Tokens may contain the following fields (known as claims):
Notice that it doesn't have always in Provided column. I think that it could be different for different APIs.
The same docs have section "Obtaining user profile information"
It explains where to get the /userinfo endpoint URL and how to call it. In the response you should receive the info you need.
My guess why it's not working in your case is that you are using /tokeninfo endpoint. It's not a part of OpenID Connect standard. It just validates the token and parses it (does the same job as https://jwt.io). And the original ID token doesn't contain that claims for some reason. Therefore /tokeninfo endpoint doesn't return them to you.
But according to Google's documentation and you should use /userinfo endpoint to obtain user info claims.
You can find description of this endpoint in OpenID Connect specification:
https://openid.net/specs/openid-connect-core-1_0.html#UserInfo
5.3 UserInfo endpoint
The UserInfo Endpoint is an OAuth 2.0 Protected Resource that returns Claims about the authenticated End-User. To obtain the requested Claims about the End-User, the Client makes a request to the UserInfo Endpoint using an Access Token obtained through OpenID Connect Authentication.
We have ADB2C tenant with a Identity Provider setup to an Okta setup in another Organization via Open ID Connect.
We have a Admin UI to add users. I see that GraphAPI has a createUser which takes a json with Password and changePwdOnFirstUse setting. This is fine to add a direct member to ADB2C.
The problem I have is that, how can I add the User from the other Okta
Organization so that when this user logs in to my App (and is authenticated by Okta), can login to my App.
At present, after authentication from Okta, we see User not found Error.
I suppose, I cannot add this user via Graph API using same createUser method as this user password is not something we are supposed to manage.
How do I add this other Organization user to ADB2C, so that I do not see this "User not found" issue?
Thanks.
Using Azure AD Graph API, you can create an external account user, with the userIdentities property of the user object being set to the sub (subject) claim of Okta's ID token:
{
"accountEnabled": false,
"displayName": "John Smith",
"mailNickname": "john.smith",
"otherMails": [
"john.smith#company.com"
],
"userIdentities": [
{
"issuer": "{okta-id-token-iss-claim-value}",
"issuerUserId": "{okta-id-token-sub-claim-value}"
}
],
"userPrincipalName": "{guid}#{your-tenant-name}.onmicrosoft.com"
}
where issuerUserId must be set to the base64 encoding for the sub claim of Okta's ID token.
I'm setting up a document esigning process using Docusign. Since we have multiple associations, We have setup multiple accounts (around 20 APIAccountID under one organization (or you can say as one INTEGRATOR_KEY_ID)) one for each association. Can someone please let me know on how do we switch to different APIAccountID based on the request we get. Also, is it the right way to create a new DocuSignConnection every time when we get the request for different association ?
Your integration should use just one INTEGRATOR_KEY for the entire integration. When using one of the DocuSign OAuth flows such as JWT as you mention.
After the user grants access by providing their credentials and clicking Accept an access token will be sent back to your app (at the redirect URI you specify on your integrator key).
You then use that access token to call the User Info API which will return account ID for that given user.
User Info API
Request:
Authorization: Bearer eyJ0eX...MrhIddzBAQ
GET https://account-d.docusign.com/oauth/userinfo
Response:
{
"sub": "4799e5e9-1559-4915-9862-cf4713bbcacc",
"name": "Susan Smart",
"given_name": "Susan",
"family_name": "Smart",
"created": "2015-08-13T22:03:03.45",
"email": "susan.smart#example.com",
"accounts": [
{
"account_id": "a4ec37d6-04aa-4f37-86c2-143885c220e1",
"is_default": true,
"account_name": "Susan Smart",
"base_uri": "https://domain.example.com",
"organization": {
"organization_id": "9c5fb8e1-b0bf-4970-8e0e-054ff8a249bf",
"links": [
{
"rel": "self",
"href": "https://account.domain.example.com/organizations/9c5fb8e1-b0bf-4970-8e0e-054ff8a249bf"
}
]
}
}
]
}
You have one application which sends signing requests on behalf of multiple associations (organizations)?
As Ergin says, your application will have one integration key which will be used for all associations.
When a human logs into you app using OAuth Auth Code Grant, your app receives an access token. You can use that access token to look up the user's account and site (API URL).
Your application can make sending requests for any number of people and their associations. Each API request includes the user's individual access token, their account_id, and uses the site data to create the URL.
HTH.
I am trying to use Google OAuth authentication for Mobile App hosted in Azure, but getting user ID (SID) in different formats.
When I access the API from browser directly, I'm redirected to Google login page, and after authentication the next request to my API comes with the headers:
"x-ms-client-principal-name":"pavlolissovtest#gmail.com",
"x-ms-client-principal-id":"108491597139717511334",
"x-ms-client-principal-idp":"google",
"x-ms-token-google-access-token":"ya29.Ci9-A-oE8p4vVelYhRKqjMKY6KGxeW4OtXT-KGtBO3AxsiBqiCawn8sxL-qg4msWrw"
In Windows Phone App (authentication with WindowsAzure.MobileServices.MobileServicesClient), when logged with the same account, request comes with different headers:
"x-ms-client-principal-id":"sid:3fc89f071b7cb8f18919614ac46d3636",
"x-ms-client-principal-idp":"google",
"x-ms-token-google-access-token":"ya29.Ci9-AxC3kfrYrV8ssLUkbwFJJYDPsklsUH7r3HG0f6KB_wWzXV9AqE_wGPASiYxcWQ"
So now I have different principal ids for the same user account.
If now I call https://www.googleapis.com/oauth2/v3/tokeninfo?access_token=, for both tokens I get the same result:
{
"azp": "1083509260178-cntp3794bggcs5dtkse0mtbvpqigoa78.apps.googleusercontent.com",
"aud": "1083509260178-cntp3794bggcs5dtkse0mtbvpqigoa78.apps.googleusercontent.com",
"sub": "108491597139717511334",
"scope": "https://www.googleapis.com/auth/plus.me https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email",
"exp": "1476643317",
"expires_in": "3161",
"email": "pavlolissovtest#gmail.com",
"email_verified": "true",
"access_type": "online"
}
This allows me to identify the user whatewer login option is used, but is it really correct to call googleapis for each request? What is the proper way of identifying the user from headers, or maybe converting one value into another?
And what is the meaning of having these values different?
Thanks for your advice!