After authentication with Add-AzureRMAccount i would like to print out the oauth token to debug its claims.
Is this possible in Azure Powershell?
No, it is not possible.
The output object from Add-AzureRMAccount only has the following properties:
Environment
Account
TenantId
SubscriptionId
CurrentStorageAccount
Even with the -Debug switch for Add-AzureRMAccount, the debug messages also do not print out the actual OAuth token, only the token hash is printed out.
Update 1: Tested again with the Microsoft Azure PowerShell January 2016 (1.1.0)
Still only show the token hash.
Related
I have a tool where I need to setup a flow that upload a file to GCS (granting rights to a service account).
Problem of the tool is that it's an UI and only support a "Oauth 2.0 Grants type Flow".
It asks for:
Authorization Server URL
clientId
client Secret
It doesn't seems possible to have an authentication by a service account with only these 3 parameters: Authorization Server URL, clientId and a client Secret
Problem of this application is that it can't use code. Otherwise I would have used Python and do it easily.
From what I understand of Oauth2 in GCP for a service account:
https://developers.google.com/identity/protocols/oauth2/service-account
https://cloud.google.com/bigquery/docs/authorization
We need to generate a JWT token by doing some signing with base64 and sha256. This is not a possible solution because the app can't use code or such algorithms.
I have the same problem with interoperability system and HMAC keys: https://cloud.google.com/storage/docs/aws-simple-migration
which requires a signature: https://cloud.google.com/storage/docs/authentication/signatures
It seems that the task is impossible unless I missed something.
Thanks for any help !
Since your software has a UI and it's asking for url/cliendID/secret there is a good chance that it will perform the token generation for you using the oauth2 protocol.
Try with the following:
Url -> https://accounts.google.com/o/oauth2/auth
ClientID -> your service account email
Secret -> your service account key secret (you have to generate a key in JSON format from the GCP Console UI by selecting the service account)
For the life of me I cannot figure this out.
I am trying to write a PowerShell Script that will get a list of solutions in a tenant
The Url to do this is as following: https://(MyCRM).dynamics.com/api/data/v9.x/solutions
Service principal items I have are: ClientId, ApplicationId, ClientSecret
In my case I am using Invoke-WebRequest
How do I build the Authentication part of the Invoke-WebRequest, to successfully get the request through?
so someone pointed me to a solution :)
basically its a two step process:
you get the access token from https://login.microsoftonline.com
than you use the token in your authorisation header for any calls you do to the server
Solution
Context
I have an application that acts as Sendgrid Webhook handler. To implement OAuth 2, I currently have an in-app authorization server based on OpenIddict. It works.
The application exchanges a local scope JWT using a local authorization endpoint, which is backed by an in-memory EF DbContext storing client ID and credential, where the credential ultimately comes from the Azure Environment (setting an env variable in the PaaS instance). As I said, it works.
The drawback is that the Sendgrid credentials (client ID and secret) are stored inside the application and I am still exchanging a local JWT with the drawback of key management. Motivating: the application currently uses an ephemeral JWK, so it can't scale horizontally until I store the key in a Key Vault or such. The problem is also by design because all our company uses MS Azure as platform, so leveraging Azure tools such as MS AAD is better than implementing our own authentication provider, despite the great work done by the open source community.
I already have an app registration on our B2C tenant, where front-end users can authenticate using OIDC (endpoint https://login.microsoftonline.com/<our-tenant-id>/v2.0/.well-known/openid-configuration). Users can log in to the application.
Question
How can I use a Microsoft-Azure-based identity to authenticate Sendgrid Webhook in machine-to-machine mode? I want the Sendgrid credentials to be stored in the cloud, not in our application (which is deployed to Azure... but you know what I mean!). Sendgrid should be configured to exchange a JWT from Microsoft Azure, and give it to our application. I want to remove the Authorization Server part from the app.
Sendgrid takes the following:
Authorization method: must be OAuth 2
Client ID
Client Secret
Token URL
HTTP POST URL, which is my application's endpoint
What I tried so far: creating an Azure AD B2C user/password for Sendgrid
Using Azure AD B2C portal, I entered our directory and created a new user sendgridhook#<our-tenant>.onmicrosoft.com with a password to enter into Sendgrid. I had configured ngrok in order to divert traffic to my local host instance, and gave it a try. Did not receive test events.
The problem was likely the authentication. I tried to run the following
❯ Invoke-WebRequest -Method Post -Uri https://login.microsoftonline.com/<tenant-guid>/oauth2/v2.0/token -ContentType "application/x-www-form-urlencoded"
-Body "client_id=sendgridhook#<tenant>.onmicrosoft.com&client_secret=<password>&grant_type=client_credentials&scope=https%3A%2F%2Fgraph.microsoft.com%2F.default"
Invoke-WebRequest: {"error":"unauthorized_client","error_description":"AADSTS700016: Application with identifier 'sendgridhook' was not found in the directory '<tenant-guid>'. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.......",
"error_codes":[700016],"timestamp":"...","trace_id":"....","correlation_id":"...","error_uri":"https://login.microsoftonline.com/error?code=700016"}
AADSTS700016: Application with identifier 'sendgridhook' was not found in the directory ''. This can happen if the application has not been installed by the administrator of the tenant or consented to by any user in the tenant. You may have sent your authentication request to the wrong tenant.......
Conclusion: probably the user must authenticate interactively, not as a machine-user
Second attempt: use App Registration's client credentials
I already use an App Registration for the implicit flow in Angular, so I tried to create a secret credential for it. Result is interesting.
❯ (Invoke-WebRequest -Method Post -Uri https://login.microsoftonline.com/<tenant-guid>/oauth2/v2.0/token -ContentType "application/x-www-form-urlencoded" -Body "client_id=<app-registration-client-id>&client_secret=<newly-generate-credential>&grant_type=client_credentials&scope=https://<tenant>.onmicrosoft.com/<app-name>/.default").Content
{"token_type":"Bearer","expires_in":3599,"ext_expires_in":3599,"access_token":"eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyIsImtpZCI6Im5PbzNaRHJPRFhFSzFqS1doWHNsSFJfS1hFZyJ9......."}
So I obtained a JWT. Now, the problem is that Sendgrid can't be configured because of the scope. The scope here was added by me, and I can't even try to barely change the url to /token?scope=[...] to hope Microsoft takes the scope from the URL.
As I said above, Sendgrid only takes client ID, client secret and token endpoint. It takes no scope.
I also ran into this and after some digging I couldn't find anyone who posted an answer to this. I have however found that if you use the v1 token endpoint it will work without specifying scope.
I am unable to create an OpenID Connect identity token to send as bearer token for a cloud run request. From the apps script I cannot make a token using (ScriptApp.getIdentityToken()) which has an audience the Google front end will allow through. When I arrange for the script to send a token instead that I've made with gcloud print-identity-token--identical except for the audience--that invocation succeeds.
Note I believe this may the same issue as seen here: Securely calling a Google Cloud Function via a Google Apps Script.
Also google cloud authentication with bearer token via nodejs.
One workaround suggests restructuring the GCP/Apps Script projects. Others mostly use service accounts, and use service account keys. I believe it's possible using IAM and use of google auth for one to produce a usable SA identity token (short term service account credentials) but I can't demonstrate it.
I am working around this currently, but I'd like to understand the essential problem. I think it has something to do with the cloud run service's hosting project's Oauth consent screen, and the inability to add the associated web application client-id as a scope.
In the Cloud Run docs, there is a section about performing authenticated calls to Cloud Run from other services outside GCP. The process would be the following:
Self-sign a service account JWT with the target_audience claim set to the URL of the receiving service.
Exchange the self-signed JWT for a Google-signed ID token, which should have the aud claim set to the above URL.
Include the ID token in an Authorization: Bearer ID_TOKEN header in the request to the service.
Step 1 could be performed as described here while setting the aud claim to the URL of the receiving service. I believe ScriptApp.getIdentityToken() does not set the proper audience to the JWT
For step 2, I believe you should perform a POST request to https://oauth2.googleapis.com/token with the appropriate parameters grant_type and assertion. This is explained in the "Making the access token request" section here
The resulting token should be used in step 3
I just wrote an article on that topic and I provide an easy way based on the service account credential API. Let's have a look on it and we can discuss further if required.
Is Jenkins has token mechanism to authorize Jenkins APIs without using username?
Thanks,
Srikanth.
Token without password supported since version 1.426
API token is new since 1.426
The API token is available in your personal configuration page
Specifying the real password is still supported after 1.426, but it is not recommended