We are integrating the Role Assignments - List API from Microsoft Azure Cloud Management APIs, Link to documentation: https://learn.microsoft.com/en-us/rest/api/authorization/roleassignments/list#errordetail
We have done all of the configs mentioned:
Registered a multi-tenant web app with Azure Active Directory for OAuth using App Registrations option,
Also enabled the https://management.azure.com/user_impersonation scope under Azure Service Management
Same scope is requested by the web app
So far OAuth succeeds but the access token received when used to call an API GET https://management.azure.com/subscriptions/{subscriptionId}/providers/Microsoft.Authorization/roleAssignments?api-version=2015-07-01 it fails with 401 Unauthorized error. I have replaced the subscriptionId with the appropriate value while making actual call.
I looked at the details of access token using https://jwt.io/ and the scp element only seems to have "scp": "User.Read" scope, Missing the user_impersonation. Though the AUTH dialog from Microsoft login service shows clearly the requested user_impersonation grant. The user account I am using for the OAuth has access to the given azure subscription.
What might be the problem?
It's important to add scope with https://management.azure.com/user_impersonation when requesting for an access token.
Test using implicit grant flow in browser:
https://login.microsoftonline.com/<tenant-id>/oauth2/v2.0/authorize?
client_id=<your-app-id>
&response_type=token
&redirect_uri=<your-redirect_uri>
&scope=https://management.azure.com/user_impersonation
&response_mode=fragment
&state=12345
&nonce=678910
Note: If you use client credentials flow, change scope to https://management.azure.com/.default.
Related
I'm rather new to AWS Cognito and AWS Lambda. So far I've played around with Serverless and deployed my REST API via AWS Lambda. However, I would like to make my API available for several external parties. As this is service to service, there is no end user directly calling my API. I make the API available for other businesses which use it in their applications. All functionalities exposed via the API are rather simple, meaning they are not invoking any other AWS services like a Dynamo DB etc.
I have several questions, some are rather high-level others are quite specific to the setup of AWS Cognito. I decided to put all in one post as it makes it much more self-contained and easier understandable.
1. Question, Cognito vs API key: What is the advantage of using AWS Cognito vs AWS Lambda in combination with restricting the access via an API key and IP-Whitelisting? Is one much more secure than other?
Let's assume I want to use AWS Cognito. As this is a service to service case, I've read that the standard is to use token endpoints where the grant_type is client_credential. I've found the following on medium. The first few steps consist of
Create a user pool in AWS Cognito.
Create an App client
Add Resource Servers
Enable the client credentials checkbox for Allower OAuth flows
2. Question, App client: Within the added App client I find the corresponding App client id and App client secret. If I expose my API to several different parties, do I need to add for each party another App client? Otherwise they use all the same credentials. Is this the right way to do it?
3. Question, Resource Server: Here I'm completely stuck. What exactly is the meaning for this? At then end, all I want is that my clients can do a post request against my API and access is granted through Cognito. Some clarification what this is for and how this applies in my case would be appreciated. More than happy to share more insights if needed.
The next part is to configure Cognito Authorizer for the API Gateway. This should be fine.
4. Question, client workflow Regarding my clients workflow. Am I correct that this consist of the following steps:
First, I provide to the client his client_id and client_secret.
then the client implements on his side the following workflow:
Whenever he wants to use my API exposed via API Gateway, he first uses his provided client_id and client_secret to retrieve his bearer token.
He uses this bearer token to make a request to API Gateway with the bearer token in the Authorization header.
If access granted, the client retrieves the output of my API.
Is this correct or am I missing anything?
1-Question, Cognito vs API key
Well as you can see here.
Amazon Cognito user pools let you create customizable authentication
and authorization solutions for your REST APIs.
Usage plans let you provide API keys to your customers — and then
track and limit usage of your API stages and methods for each API key
So the purpose is different, the API Key is used basically to count a customer usage while AWS Cognito is there to authenticate/authorize calls to your API.
Let us say, you have a requirement that a trail user can't call your API more than 100 times.
Then using AWS Cognito, you will allow a user to sign up, also you will provide the same user with an API Key, you will identify the source of the calls using Cognito and with each call API Gateway will decrease the limit assigned to user's API Key by 1.
And you will have the following cases:
When token (obtained through login using username and password), and
API Key are valid, then the call will be successful.
When token is wrong/missing, your caller will get 401 status code.
When API Key is wrong/missing, your caller will get 403 status code.
When API Key is correct but limit is exceeded, your caller will get
429 status code.
2. Question, App client:
Well, client id and client secrets are meant to identify a trusted client (app) rather than a user and each app should have its own client id, so if the caller is an application not a user so yes, create a client id for each separate app. Please be aware that client secrets must be kept confidential so if the caller app can't achieve that, such as single-page Javascript apps or native apps, then the secret shouldn't be issued.
3. Question, Resource Server:
It is your API server.
Check this page.
The resource server is the OAuth 2.0 term for your API server. The
resource server handles authenticated requests after the application
has obtained an access token.
Large scale deployments may have more than one resource server.
Google’s services, for example, have dozens of resource servers, such
as the Google Cloud platform, Google Maps, Google Drive, Youtube,
Google+, and many others. Each of these resource servers are
distinctly separate, but they all share the same authorization server.
4. Question, client workflow
Check Client credentials grant in here
The steps for the process are as follows:
An app makes a POST request to https://AUTH_DOMAIN/oauth2/token, and specifies the following parameters:
grant_type – Set to “client_credentials” for this grant type.
client_id – The ID for the desired user pool app client.
scope – A space-separated list of scopes to request for the generated access token.
In order to indicate that the app is authorized to make the request, the Authorization header for this request is set as “Basic
BASE64(CLIENT_ID:CLIENT_SECRET)“, where
BASE64(CLIENT_ID:CLIENT_SECRET) is the base64 representation of the
app client ID and app client secret, concatenated with a colon.
The Amazon Cognito authorization server returns a JSON object with the following keys:
access_token – A valid user pool access token.
expires_in – The length of time (in seconds) that the provided access token is valid for.
token_type – Set to ” Bearer“.
Note that, for this grant type, an ID token and a refresh token aren’t returned.
The app uses the access token to make requests to an associated resource server.
The resource server validates the received token and, if everything checks out, executes the request from the app.
We are experiencing problems with Authentication of Service Accounts for domain-wide delegation.
The main problem is it's hard to investigate and debug the auth configuration so
we would like to ask for some tips how to debug the configuration.
Or maybe we are missing some configuration options and you can point us to them.
Our process is:
Create SA(=Service Account) with enabled domain-wide delegation.
Authenticate SA in GSuite admin console(https://support.google.com/a/answer/162106?hl=en).
use client_id from the credentials file. (now email)
scopes are comma-separated without spaces between.
Ensure the "Security > API Reference > API Reference -> 'Enable API Access'" is checked.
For some GSuite domains this is working configuration, but we got some domains where this configuration results in:
google.auth.exceptions.RefreshError: ('unauthorized_client: Client is unauthorized to retrieve access tokens using this method.', '{\n "error": "unauthorized_client",\n "error_description": "Client is unauthorized to retrieve access tokens using this method."\n}')
In our understanding, this is the error saying the client_id and scopes were not added to the "Manage API client access" page. (=List of authenticated clients)
We really ensured that the GSuite domain we are requesting has the proper client_id and scopes added in the list of authenticated clients + has the 'Enabled API Access'.
We even created Shared Desktop with them and did it by ourselves to be fully sure of it.
But the error still persists.
However, we are not able to replicate this problem on our test GSuite domain.
We tried couple of options using same SA as the client:
The impersonated account hasn't permissions to access the resource.
This result in:
googleapiclient.errors.HttpError: https://www.googleapis.com/admin/directory/v1/users?customer=my_customer&alt=json returned "Not Authorized to access this resource/api">
The scopes are just partial:
google.auth.exceptions.RefreshError: ('access_denied: Requested client not authorized.', '{\n "error": "access_denied",\n "error_description": "Requested client not authorized."\n}')
The 'Enabled API Access' is not checked.
googleapiclient.errors.HttpError: https://www.googleapis.com/admin/directory/v1/users?customer=my_customer&alt=json returned "Domain cannot use apis.">
The error we are receiving from the client("Client is unauthorized to retrieve access tokens using this method."), we are able to replicate only if the client_id is not in the list of authenticated clients at all.
But we are sure, the problematic GSuite domains have the SA authenticated in "Manage API client access" page.
We are using these scopes: https://www.googleapis.com/auth/userinfo.profile,https://www.googleapis.com/auth/userinfo.email,https://www.googleapis.com/auth/gmail.readonly,https://www.googleapis.com/auth/plus.login,https://www.googleapis.com/auth/calendar.readonly,https://www.googleapis.com/auth/contacts.readonly, https://www.googleapis.com/auth/admin.directory.user.readonly
Do you have any ideas how to debug/solve this issue?
Here is what you need to do. Double check each step. If in doubt, start over.
Enable "Admin SDK API. This is enabled on a per project basis.
Create a service account. Do not add or remove any privileges. Don't change the service account in any way. If you do you will get an error that you are not authorized.
Enable Domain-wide Delegation on the service account.
Follow this document to delegate domain-wide authority to your service account:
Delegate domain-wide authority to your service account
When creating the service account credentials (from the downloaded Json) you will need the following scopes for full G Suite management:
"https://www.googleapis.com/auth/admin.directory.group",
"https://www.googleapis.com/auth/admin.directory.user"
Impersonate a user account which creates new credentials. The user account needs to be a G Suite superadmin. This account must have logged into G Suite at least once and accepted the Terms of Service.
Create your client using the credentials from step #5.
Working Python Example:
from googleapiclient.discovery import build
from google.oauth2 import service_account
# This is the service account credentials file
credentials_file = 'google-directory-api.json'
# In this example I only need to send email
credentials = service_account.Credentials.from_service_account_file(
credentials_file,
scopes=['https://www.googleapis.com/auth/gmail.send'])
# This user is a G Suite superadmin
impersonate = 'username#example.com'
credentials = credentials.with_subject(impersonate)
service = build('gmail', 'v1', credentials=credentials)
I think we are going to need to take this in stages. Lets start with your first error and see if that fixes your issue.
Background info
There are several types of clients that you can create in Google developer console. Here are the top three.
Browser client: Used for web applications
Native client (other): used for installed desktop applications
Service account: used for server to server communication.
The clients are different the client.json file you download is different and the code used to authenticated to the authentication server is also different.
Error 1: code / client missmatch
unauthorized_client: Client is unauthorized to retrieve access tokens using this method.
Can mean one of two things. Either you have created a service account client and you are not using service account code to authenticate or you are are using the code to authenticate with a service account but you have not created a service account client. You haven't posted what language you are using or any code so I cant tell you if the code you are using is intended to be used with a service account or not. Your going to have to look into this one a bit.
Check in developer console make sure your client is like this If it is check your code. If it isnt then create a real service account client and try again.
I have an issue with a web api returning HTTP 401 – Unauthorized when I use a Bearer Token to access it from a xamarin client. Either the iOS or UWP fail.
-This is an application that authenticates with Azure Active Directory to allow a user to login
-Once successfully logged in it gets a token that in turn is added to the web api request header
-The web api has its authentication turn on
The issue with azure settings
https://1drv.ms/v/s!ApPhjsvemKJggpR2ax5w4wRJcY7uXQ
the code
https://github.com/wleon12/XamarinForms-AAD-WebAPI.git
I cant seem to figure out what is wrong, appreciate any input or guidance
It depends how you protect the web API.
Normally, when we protect the web API using Azure AD, we will provide the the Audience and Tenant like this code sample. So that when we send the request with the token, the web API will verify the signature of the token and the value we config.
So for the 401 issue, please check the token you acquired with the value you config for the web API project. To check the Audience, Tenant and other values in the token, you can decode it from this site.
I'm following https://aws.amazon.com/blogs/security/how-to-set-up-federated-single-sign-on-to-aws-using-google-apps/ and attempting to set up a script to patch my Google users with SSO AWS roles.
Using the scope listed at https://developers.google.com/admin-sdk/directory/v1/reference/users/patch , I've authenticated properly and have confirmed by doing a simple:
service.users().list(customer='my_customer', maxResults=10, orderBy='email').execute()
This returns successfully with a list of users. However, when I try to execute a patch query with:
service.users().patch(body=body, userKey=user_email).execute()
The response is "Not Authorized to access this resource/api".
Is this endpoint special in some way? It appears the only way to successfully access this resource is by authenticating with a super admin account, which I would prefer not to do.
Please note that it was mentioned in Directory API: Authorize Requests that,
Your application must use OAuth 2.0 to authorize requests. No other authorization protocols are supported. If your application uses Google Sign-In, some aspects of authorization are handled for you.
With this, I suggest that you use Authorizing requests with OAuth 2.0.
You may also check other possibilities why such error can be encountered from these SO posts:
Google_Service_Directory - (403) Not Authorized to access this resource/api
The root of the problem is that the service account is not an administrator on the domain, so it cannot access the Admin SDK Directory API. Instead, you need to enable domain-wide delegation for your service account, and then have the service account impersonate a domain admin when it makes the request.
Google Directory API returns Not Authorized when call users().list().execute()
Hope that helps!
I am trying to build an AzureAD access app. I have to enable this app for external tenants. I have enabled external access on this app and it is configured to use the Graph API also. I have tested the app in the tenant in which it was created and everything(auth+ graph api access) works. Now here is the flow for the external tenant
I take the external tenant user to the grant consent URL of my app, the user(who is an admin of the external tenant) grants the access and i get the correct response
Now i want to get the authorization token for this user, so i take the user through the normal Oauth process via
https://login.windows.net/common/oauth2/authorize
followed by
https://login.windows.net/common/oauth2/token/
At this point Azure throws the following error
{"error":"invalid_grant","error_description":"AADSTS50000: There was an error issuing a
token. AADSTS65005: No permission to access \u0027https://graph.windows.net\u0027
resource is configured for \u0027d2037ff7-24e4-4cac-8e5e-16e370b36238\u0027 application,
or it is expired or revoked.\r\nTrace ID: 472aa92f-35a2-4ed9-ab07-
12488cc9e6f5\r\nCorrelation ID: b163dde5-eac5-4c82-99ad-0e1100487cb9\r\nTimestamp: 2013-
09-23 05:28:41Z","error_codes":[50000,65005],"timestamp":"2013-09-23
05:28:41Z","trace_id":"472aa92f-35a2-4ed9-ab07-12488cc9e6f5","correlation_id":"b163dde5-
eac5-4c82-99ad-0e1100487cb9"}
Why this error even when the app has been granted access. I tried to lookup the STS errors
but found no explanation. Any ideas?
[update]
SAML process continues to work for the external tenant however i.e I can use the app for SAML(SSO) login for this external tenant. The problem only seems to be coming for getting access to the graph API.
Try adding &prompt=consent or &prompt=admin_consent to the full authorize URL to re-request the user consent. My experience has been that the consent will be randomly revoked (maybe a bug) and will not ever be automatically re-requested (definitely a bug).