We are implementing an application for GCP which needs the oauth2 bearer token to authenticate docker against GCR. The application is written in Go and it uses the GCP SDK for Golang.
I'd like to get what gcloud auth print-access-token give from the SDK, but I don't find how to do it...
Have a look at oauth2/google.
You may (!?) be able to use workload identity federation (using this library too and thereby avoid using a Google Service Account key) but, using a Service Account (with roles/storage.objectAdmin see GCR: Granting IAM roles) and Application Default Credentials (export GOOGLE_APPLICATION_CREDENTIALS=/path/to/your/key.json) look at DefaultTokenSource.
The Token returned by Token() from TokenSource gives you an access_token (and refresh_token and expiry).
Update
You can use the Service Account key file directly to authenticate a Docker client to GCR. This would simplify your code (and avoid refreshing). The document reiterates the caution in using Service Account keys.
Related
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.
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 trying to use service account auth with our backend service to work with Google Cloud Storage JSON API. But cannot findout exactly how it should be done. We found examples for use with Client Libs but we are working with REST API. Can someone explain to me how to setup service account auth in POSTMAN?
I’m not sure how to set this up on POSTMAN but perhaps with the following information you can figure it out:
To authenticate with a service account to Storage API or any Google Cloud REST API you need to generate an OAuth Token and include it in your request headers. To accomplish this, you need the Cloud SDK, since you will print the token with the gcloud command. The steps are as follows:
Create a new service account and generate a JSON key file.
Copy the JSON key file and install Cloud SDK in the computer where you will make the API calls from.
Use the gcloud tool to activate the service account:
gcloud auth activate-service-account --key-file=/path/file.json
Generate an access token and save it to an environment variable:
ACCESS_TOKEN="$(gcloud auth print-access-token)"
Include the access token in your request headers,like this:
"Authorization: Bearer $ACCESS_TOKEN"
I was able to find this link on how to access environmental variables from POSTMAN and this one on how to set a Bearer token, hopefully they'll help as well.
I have a working oauth2 application using v1.0 of Azure REST API. I am able to acquire access token via ADAL library for Java and no problem accessing their resources.
However, I wanted to know if there is a way to use this same token in order to let Office365/Outlook users to login on a web browser without entering a password ? Something like https://outlook.office365.com/token=abc..
This will help us to let users SSO on different devices without typing their passwords.
Technically, yes you can. You can try to leverage Microsoft Graph API to achieve your requirement.
Add the permission of Microsoft Graph in your AAD application, refer to https://graph.microsoft.io/en-us/docs/authorization/auth_overview for more info.
Follow OAuth2's Authorization Code Grant Flow to generate an access token, or leveraging your ADAL, please refer to https://graph.microsoft.io/en-us/docs/authorization/app_authorization for details.
Set the access token in the request header the same as you call Azure Rest APIs.
GET https://graph.microsoft.com/v1.0/users/john.doe#contoso.onmicrosoft.com HTTP/1.1
Authorization : Bearer <access_token>
For outlook APIs, you can refer to https://graph.microsoft.io/en-us/docs/api-reference/v1.0/resources/message for more info.
I’m trying to get my head around how I would introduce token-based (key-based?) authentication to a web API (currently looking at Sinatra, but maybe Rails too) that would be used by a mobile client and how OAuth would fit into the picture.
So, let’s say I want to create a web service that uses Facebook for authentication and grabbing basic user data. Here, my API would be a client to Facebook’s OAuth Server, requesting an access token upon a user’s successful login to Facebook. This would then grant me access to the user’s data which I would use to create an entry in my database, storing this user-specific token with any other application information I would like linked to them.
I think I got that part right so far, but here’s where I’m a bit confused.
I think that my API would also need some form of API key to grant access to a mobile user, since I wouldn’t want to transmit and store the Facebook key on their device. Would I have to have a separate store of keys which I provide to the client to access my service? Are there any ‘best practice’ ways of doing this?
Would I have to have a separate store of keys which I provide to the client to access my service?
yes.
Are there any ‘best practice’ ways of doing this?
The simplest way would be to generate a separate authentication token on every User creation and expose that to the mobile client. Then send it with every subsequent request header.
Devise provides a simple example how to achieve that. You don't need devise for that, just provide some token generation mechanism.
#Devise.friendly_token
def self.friendly_token
SecureRandom.urlsafe_base64(15).tr('lIO0', 'sxyz')
end
This mechanism can be extended to provide more security in following ways
Being an oauth2 provider itself.
On successfull login with facebook, you would generate an :authorization_code which the client can exchange for your own Oauth2 Bearer or MAC token within a next step. Then you can send your own Oauth2 token with every request for user authentication.
See rack-oauth2
Implement HMAC token encryption.
Generate and expose a secret_key to every client after singning in. Use this secret to sign messages along with a unique client id. The server can then lookup the secret_key for the specific client_id and verify the message.
See api-auth