Getting AzureAD implicit flow working with Swagger UI - azure-active-directory

As an exercise, I have been attempting to create a swagger configuration that can invoke the Azure Management API, and to run this from the online swagger editor.
I have configured it to use implicit authentication, and it almost works, but I just cannot get the Azure Framework to recognize the swagger editor as a valid redirect URL.
Here is all the steps I have taken. Can anyone spot what I'm doing wrong?
Using the Azure AD portal, I create a new Azure AD Application
In the application registration's Reply URL's, I added https://editor.swagger.io/oauth2-redirect.html
I created the following security entries in my Swagger 2.0 document:
securityDefinitions:
azureTokenAuthentication:
flow: implicit
authorizationUrl: https://login.microsoft.com/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/oauth2/authorize
scopes:
https://management.azure.com: Accessing the Azure API
type: oauth2
security:
- azureTokenAuthentication:
- https://management.azure.com
(The redacted GUID is my tenant id).
Now, when I click on the "Authorization" button, swagger opens up a dialog for me:
So I enter the application ID and click authorize. It then sends me to the logon URL with the following parameters:
response_type: token
client_id: eb482fb2-8229-434e-b5a6-9fc3e0f06968
redirect_uri: https://editor.swagger.io/oauth2-redirect.html
scope: https://management.azure.com
state: <Base64 string>Wed Mar 13 2019 09:16:06 GMT+1000 (Australian Eastern Standard Time)
Note that the redirect uri matches the value I entered in the app registration.
So I enter my username and password, and then the URL gets redirected to the following:
https://login.live.com/err.srf?lc=1033#error=invalid_request&error_description=The+provided+value+for+the+input+parameter+'redirect_uri'+is+not+valid.+The+expected+value+is+a+URI+which+matches+a+redirect+URI+registered+for+this+client+application.&state=rQIIAdNiNtQztFJJTTKxMEpLMtK1MDKy1DUxNknVTTJNNNO1TEs2TjVIMzCzNLMoEuISWF1yo3vvud0Ozb9b9Z66bQ-cxcgZn5NZlqqXnJ-7ilEvo6SkoNhKXz81JbMkv0ivuDwxPT21SC8zXz8_sbQkw0i3CChTlJpcAlSZm7ODkfECI-MLRsZbTPz-jiB5EJFflFmVOos5JswoLNvT1TAjOdOxwrfSsdLXxdXU08XR1D_L1cg_y9HI0zXFL8y5uMLXxbHc0znDKSXCzyA51604Mdyt1NM1LCPZOCgnOdckPdQ4KCMpNygjOTcwPcw9pyQqONt2E7NKSqqpuZGhmZGuabJ5iq6JRVqSrmWSqaGuubmlabKpeaKZqWXyKWYZmI9yE_MS01NzU_NK9BKrSovAHr7BzHiBhfEVC48BsxUHB5cAgwSDAsMPFsZFrMCQmrTR22we8wzHyc1Bd633_2M4xapfku7mkeJk5qxfkpOb7lcUXB5SmOZb7Jef7l-c526UmVUQqV_q5Zzh4uzma2tkZTiBTeYDG2MHO8MuThID9haXiJGBoaWugbGuoZGCkbGVoZmVgXkUAA2
The interesting text I glean from this is:
The provided value for the input parameter 'redirect_uri' is not valid. The expected value is a URI which matches a redirect URI registered for this client application.
But it DOES match! What am I doing wrong?!?

reply url = "your web api's swagger page url" concatenated with "/oauth2-redirect.html"
example: https://localhost:44329/swagger/oauth2-redirect.html
configure that for each environment in your app registration including your localhost.

First of all, I changed the authorization URL from https://login.microsoft.com/<tenant-id>/oauth2/authorize to https://login.microsoft.com/<tenant-id>/oauth2/v2.0/authorize
I then had to follow these instructions, and directly modify the application manifest to allow implicit flow:
Then I changed the scopes. I could not get management.azure.com running, but I could get https://graph.windows.net by appending /.default to the scope. (https://graph.windows.net/.default).
That got me another step further. Now it redirected to the Authorization URL, and Microsoft authenticated me, generated a token for me, and redirected my browser to https://editor.swagger.io/oauth2-redirect.html
Then I was thwarted, when I realised that editor.swagger.io does not actually handle the path it's redirecting the browser to. (The file outh2-redirect.html exists on GitHub here: https://github.com/swagger-api/swagger-ui/blob/master/dist/oauth2-redirect.html)
That's when I gave up.

Related

GMAIL API ACCESS ISSUE [duplicate]

On the website https://code.google.com/apis/console I have registered my application, set up generated Client ID: and Client Secret to my app and tried to log in with Google.
Unfortunately, I got the error message:
Error: redirect_uri_mismatch
The redirect URI in the request: http://127.0.0.1:3000/auth/google_oauth2/callback did not match a registered redirect URI
scope=https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/userinfo.email
response_type=code
redirect_uri=http://127.0.0.1:3000/auth/google_oauth2/callback
access_type=offline
approval_prompt=force
client_id=generated_id
What does mean this message, and how can I fix it?
I use the gem omniauth-google-oauth2.
The redirect URI (where the response is returned to) has to be registered in the APIs console, and the error is indicating that you haven't done that, or haven't done it correctly.
Go to the console for your project and look under API Access. You should see your client ID & client secret there, along with a list of redirect URIs. If the URI you want isn't listed, click edit settings and add the URI to the list.
EDIT: (From a highly rated comment below) Note that updating the google api console and that change being present can take some time. Generally only a few minutes but sometimes it seems longer.
In my case it was www and non-www URL. Actual site had www URL and the Authorized Redirect URIs in Google Developer Console had non-www URL. Hence, there was mismatch in redirect URI. I solved it by updating Authorized Redirect URIs in Google Developer Console to www URL.
Other common URI mismatch are:
Using http:// in Authorized Redirect URIs and https:// as actual URL, or vice-versa
Using trailing slash (http://example.com/) in Authorized Redirect URIs and not using trailing slash (http://example.com) as actual URL, or vice-versa
Here are the step-by-step screenshots of Google Developer Console so that it would be helpful for those who are getting it difficult to locate the developer console page to update redirect URIs.
Go to https://console.developers.google.com
Select your Project
Click on the menu icon
Click on API Manager menu
Click on Credentials menu. And under OAuth 2.0 Client IDs, you will find your client name. In my case, it is Web Client 1. Click on it and a popup will appear where you can edit Authorized Javascript Origin and Authorized redirect URIs.
Note: The Authorized URI includes all localhost links by default, and any live version needs to include the full path, not just the domain, e.g. https://example.com/path/to/oauth/url
Here is a Google article on creating project and client ID.
If you're using Google+ javascript button, then you have to use postmessage instead of the actual URI. It took me almost the whole day to figure this out since Google's docs do not clearly state it for some reason.
In any flow where you retrieved an authorization code on the client side, such as the GoogleAuth.grantOfflineAccess() API, and now you want to pass the code to your server, redeem it, and store the access and refresh tokens, then you have to use the literal string postmessage instead of the redirect_uri.
For example, building on the snippet in the Ruby doc:
client_secrets = Google::APIClient::ClientSecrets.load('client_secrets.json')
auth_client = client_secrets.to_authorization
auth_client.update!(
:scope => 'profile https://www.googleapis.com/auth/drive.metadata.readonly',
:redirect_uri => 'postmessage' # <---- HERE
)
# Inject user's auth_code here:
auth_client.code = "4/lRCuOXzLMIzqrG4XU9RmWw8k1n3jvUgsI790Hk1s3FI"
tokens = auth_client.fetch_access_token!
# { "access_token"=>..., "expires_in"=>3587, "id_token"=>..., "refresh_token"=>..., "token_type"=>"Bearer"}
The only Google documentation to even mention postmessage is this old Google+ sign-in doc. Here's a screenshot and archive link since G+ is closing and this link will likely go away:
It is absolutely unforgivable that the doc page for Offline Access doesn't mention this. #FacePalm
For my web application i corrected my mistake by writing
instead of : http://localhost:11472/authorize/
type : http://localhost/authorize/
Make sure to check the protocol "http://" or "https://" as google checks protocol as well.
Better to add both URL in the list.
1.you would see an error like this
2.then you should click on request details
after this , you have to copy that url and add this on https://console.cloud.google.com/
go to https://console.cloud.google.com/
click on Menu -> API & Services -> Credentials
you would see a dashboard like this ,click on edit OAuth Client
now in Authorized Javascript Origins and Authorized redirect URLS
add the url that has shown error called redirect_uri_mismatch i.e here it is
http://algorithammer.herokuapp.com , so i have added that in both the places in
Authorized Javascript Origins and Authorized redirect URLS
click on save and wait for 5 min and then try to login again
This seems quite strange and annoying that no "one" solution is there.
for me http://localhost:8000 did not worked out but http://localhost:8000/ worked out.
This answer is same as this Mike's answer, and Jeff's answer, both sets redirect_uri to postmessage on client side. I want to add more about the server side, and also the special circumstance applying to this configuration.
Tech Stack
Backend
Python 3.6
Django 1.11
Django REST Framework 3.9: server as API, not rendering template, not doing much elsewhere.
Django REST Framework JWT 1.11
Django REST Social Auth < 2.1
Frontend
React: 16.8.3, create-react-app version 2.1.5
react-google-login: 5.0.2
The "Code" Flow (Specifically for Google OAuth2)
Summary: React --> request social auth "code" --> request jwt token to acquire "login" status in terms of your own backend server/database.
Frontend (React) uses a "Google sign in button" with responseType="code" to get an authorization code. (it's not token, not access token!)
The google sign in button is from react-google-login mentioned above.
Click on the button will bring up a popup window for user to select account. After user select one and the window closes, you'll get the code from the button's callback function.
Frontend send this to backend server's JWT endpoint.
POST request, with { "provider": "google-oauth2", "code": "your retrieved code here", "redirect_uri": "postmessage" }
For my Django server I use Django REST Framework JWT + Django REST Social Auth. Django receives the code from frontend, verify it with Google's service (done for you). Once verified, it'll send the JWT (the token) back to frontend. Frontend can now harvest the token and store it somewhere.
All of REST_SOCIAL_OAUTH_ABSOLUTE_REDIRECT_URI, REST_SOCIAL_DOMAIN_FROM_ORIGIN and REST_SOCIAL_OAUTH_REDIRECT_URI in Django's settings.py are unnecessary. (They are constants used by Django REST Social Auth) In short, you don't have to setup anything related to redirect url in Django. The "redirect_uri": "postmessage" in React frontend suffice. This makes sense because the social auth work you have to do on your side is all Ajax-style POST request in frontend, not submitting any form whatsoever, so actually no redirection occur by default. That's why the redirect url becomes useless if you're using the code + JWT flow, and the server-side redirect url setting is not taking any effect.
The Django REST Social Auth handles account creation. This means it'll check the google account email/last first name, and see if it match any account in database. If not, it'll create one for you, using the exact email & first last name. But, the username will be something like youremailprefix717e248c5b924d60 if your email is youremailprefix#example.com. It appends some random string to make a unique username. This is the default behavior, I believe you can customize it and feel free to dig into their documentation.
The frontend stores that token and when it has to perform CRUD to the backend server, especially create/delete/update, if you attach the token in your Authorization header and send request to backend, Django backend will now recognize that as a login, i.e. authenticated user. Of course, if your token expire, you have to refresh it by making another request.
Oh my goodness, I've spent more than 6 hours and finally got this right! I believe this is the 1st time I saw this postmessage thing. Anyone working on a Django + DRF + JWT + Social Auth + React combination will definitely crash into this. I can't believe none of the article out there mentions this except answers here. But I really hope this post can save you tons of time if you're using the Django + React stack.
In my case, my credential Application type is "Other". So I can't find Authorized redirect URIs in the credentials page. It seems appears in Application type:"Web application". But you can click the Download JSON button to get the client_secret.json file.
Open the json file, and you can find the parameter like this: "redirect_uris":["urn:ietf:wg:oauth:2.0:oob","http://localhost"]. I choose to use http://localhost and it works fine for me.
When you register your app at https://code.google.com/apis/console and
make a Client ID, you get a chance to specify one or more redirect
URIs. The value of the redirect_uri parameter on your auth URI has to
match one of them exactly.
Checklist:
http or https?
& or &?
trailing slash(/) or open ?
(CMD/CTRL)+F, search for the exact match in the credential page. If
not found then search for the missing one.
Wait until google refreshes it. May happen in each half an hour if you
are changing frequently or it may stay in the pool. For my case it was almost half an hour to take effect.
for me it was because in the 'Authorized redirect URIs' list I've incorrectly put https://developers.google.com/oauthplayground/ instead of https://developers.google.com/oauthplayground (without / at the end).
The redirect url is case sensitive.
In my case I added both:
http://localhost:5023/AuthCallback/IndexAsync
http://localhost:5023/authcallback/indexasync
If you use this tutorial: https://developers.google.com/identity/sign-in/web/server-side-flow then you should use "postmessage".
In GO this fixed the problem:
confg = &oauth2.Config{
RedirectURL: "postmessage",
ClientID: ...,
ClientSecret: ...,
Scopes: ...,
Endpoint: google.Endpoint,
}
beware of the extra / at the end of the url
http://localhost:8000 is different from http://localhost:8000/
It has been answered thoroughly but recently (like, a month ago) Google stopped accepting my URI and it would not worked. I know for a fact it did before because there is a user registered with it.
Anyways, the problem was the regular 400: redirect_uri_mismatch but the only difference was that it was changing from https:// to http://, and Google will not allow you to register http:// redirect URI as they are production publishing status (as opposed to localhost).
The problem was in my callback (I use Passport for auth) and I only did
callbackURL: "/register/google/redirect"
Read docs and they used a full URL, so I changed it to
callbackURL: "https://" + process.env.MY_URL+ "/register/google/redirect"
Added https localhost to my accepted URI so I could test locally, and it started working again.
TL;DR use the full URL so you know where you're redirecting
2015 July 15 - the signin that was working last week with this script on login
<script src="https://apis.google.com/js/platform.js" async defer></script>
stopped working and started causing Error 400 with Error: redirect_uri_mismatch
and in the DETAILS section: redirect_uri=storagerelay://...
i solved it by changing to:
<script src="https://apis.google.com/js/client:platform.js?onload=startApp"></script>
Rails users (from the omniauth-google-oauth2 docs):
Fixing Protocol Mismatch for redirect_uri in Rails
Just set the full_host in OmniAuth based on the Rails.env.
# config/initializers/omniauth.rb
OmniAuth.config.full_host = Rails.env.production? ? 'https://domain.com' : 'http://localhost:3000'
REMEMBER: Do not include the trailing "/"
None of the above solutions worked for me. below did
change authorised Redirect urls to - https://localhost:44377/signin-google
Hope this helps someone.
My problem was that I had http://localhost:3000/ in the address bar and had http://127.0.0.1:3000/ in the console.developers.google.com
Just make sure that you are entering URL and not just a domain.
So instead of:
domain.com
it should be
domain.com/somePathWhereYouHadleYourRedirect
Anyone struggling to find where to set redirect urls in the new console: APIs & Auth -> Credentials -> OAuth 2.0 client IDs -> Click the link to find all your redirect urls
My two cents:
If using the Google_Client library do not forget to update the JSON file on your server after updating the redirect URI's.
I also get This error Error-400: redirect_uri_mismatch
This is not a server or Client side error but you have to only change by checking that you haven't to added / (forward slash) at the end like this
redirecting URL list ❌:
https://developers.google.com/oauthplayground/
Do this only ✅:
https://developers.google.com/oauthplayground
Let me complete #Bazyl's answer: in the message I received, they mentioned the URI
"http://localhost:8080/"
(which of course, seems an internal google configuration). I changed the authorized URI for that one,
"http://localhost:8080/" , and the message didn't appear anymore... And the video got uploaded... The APIS documentation is VERY lame... Every time I have something working with google apis, I simply feel "lucky", but there's a lack of good documentation about it.... :( Yes, I got it working, but I don't yet understand neither why it failed, nor why it worked... There was only ONE place to confirm the URI in the web, and it got copied in the client_secrets.json... I don't get if there's a THIRD place where one should write the same URI... I find nor only the documentation but also the GUI design of Google's api quite lame...
I needed to create a new client ID under APIs & Services -> Credentials -> Create credentials -> OAuth -> Other
Then I downloaded and used the client_secret.json with my command line program that is uploading to my youtube account. I was trying to use a Web App OAuth client ID which was giving me the redirect URI error in browser.
I have frontend app and backend api.
From my backend server I was testing by hitting google api and was facing this error. During my whole time I was wondering of why should I need to give redirect_uri as this is just the backend, for frontend it makes sense.
What I was doing was giving different redirect_uri (though valid) from server (assuming this is just placeholder, it just has only to be registered to google) but my frontend url that created token code was different. So when I was passing this code in my server side testing(for which redirect-uri was different), I was facing this error.
So don't do this mistake. Make sure your frontend redirect_uri is same as your server's as google use it to validate the authenticity.
The main reason for this issue will only come from chrome and chrome handles WWW and non www differently depending on how you entered your URL in the browsers and it searches from google and directly shows the results, so the redirection URL sent is different in a different case
Add all the possible combinations you can find the exact url sent from fiddler , the 400 error pop up will not give you the exact http and www infromation
Try to do these checks:
Bundle ID in console and in your application. I prefer set Bundle ID of application like this "org.peredovik.${PRODUCT_NAME:rfc1034identifier}"
Check if you added URL types at tab Info just type your Bundle ID in Identifier and URL Schemes, role set to Editor
In console at cloud.google.com "APIs & auth" -> "Consent screen" fill form about your application. "Product name" is required field.
Enjoy :)

How to get data from Microsoft Bing Ads API

I'm trying to get Bing ads spends from my firm. According to the Microsoft documentation, I understood that it's mandatory to use Microsoft Azure portal, get developer_token, client_id, tenant_id, client_secret, and access/refresh token to download the csv files with the data I want.
So, this is what I did:
I've received an invitation from my firm to Microsoft advertising onto this email adress:
abc#myfirm.fr, and I've generated my developer token.
With this email address, I've created a web application onto Microsoft Azure portal, which allow all king of users. Getting client_id, tenant_id, and generated a client_secret.
The redirect URL that I have chosen is http://localhost (according to the documentation but not sure this is the good URL to choose).
With Postman, I have tried with this endpoint:
https://login.microsoftonline.com/common/oauth2/v2.0/authorize
and the params (previously obtained) needed for the OAuth 2.0 authentication to get my access token. Without success.
The issue is here.
When I request the access token, a new browser window opens, and asks for an email address on which to authenticate. I'm using my email address abc#myfirm.fr and I received authentication completed onto Postman but into the response body I have access_token: invalid.
The role of my account is super admin.
So I'm trying to authenticate with a professional Microsoft Azure Account and this time I received into the browser Invalid redirect url.
I have also tried to start all over again with different email address, like my personal email address, or with the email address of the creator of the Microsoft Advertising account, and I get the error contact your system Admin into the browser.
I have also tried with the Python SDK project given in the documentation, with the error message.
I must have forgotten or misunderstood something.
Should we use the same email address (or same account) on Microsoft Advertising, on Microsoft Azure, and when obtaining the access token?
Do you have to pay and take an Azure subscription? (Already done but without success)
Thanks in advance, sorry for my English.
EDIT:
Thank for ypur reply. The full request is: https://login.microsoftonline.com/common/oauth2/v2.0/authorize with the following params:
-type: OAuth 2.0
-Header Prefix: Bearer
-Grant Type: Authorization Code
-Callback URL: https://localhost
-Auth URL: https://login.microsoftonline.com/{my-tenant_id}/oauth2/v2.0/authorize
-Access Token URL: https://login.microsoftonline.com/{my-tenant_id}/oauth2/v2.0/token
-my client id
-my client secret
-scope: https://ads.microsoft.com/ads.manage OR also testing with https://graph.microsoft.com/User.Read
-State: None
-Client authentication: send client credentials in body
Give me an access_token but when I click on use token and send the request, I'm not getting an refresh token
Once a user provides consent, you can get an access token and act on behalf of the user.
So when the browser session starts, you should enter your Microsoft Advertising credentials.
Remember to set scope=https://ads.microsoft.com/ads.manage in the request for acquiring the authorization code.
If you prefer to automate this process, you can refer to this script and steps to obtain an access token.

Azure AD B2C. ROPC flow error The application associated with client id has no registered redirect URIs

The application associated with client id 09ac92da-a796-4cd9-973b-c97756____ has no registered redirect URIs
Description
I followed the steps described in https://learn.microsoft.com/en-us/azure/active-directory-b2c/configure-ropc?tabs=applications.
When attempting to obtain the token in Postman using ROPC I'm getting
{
"error": "invalid_request",
"error_description": "AADB2C90007: The application associated with client id '09ac92da-a796-4cd9-973b-c97756____' has no registered redirect URIs.\r\nCorrelation ID: e85003c3-cfd5-43ad-a74b-efa5c1ea6525\r\nTimestamp: 2019-12-06 19:47:42Z\r\n"
}
I should not be asked for a redirect URIs.
My POST is as follows:
URL: ''https://mytenant.b2clogin.com/mytenant.onmicrosoft.com/oauth2/v2.0/token?p=B2C_1_ROPC_Auth"
username: some_username_of_a_user
password: its-password
grant_type: password
scope: openid offline_access 09ac92da-a796-4cd9-973b-c97756____
client_id: 09ac92da-a796-4cd9-973b-c97756____
response-type: token id_token
I didn't reproduce your issue by following this document. Here are the main steps for your reference.
1.Create a resource owner user flow
2.Register an application(It is an application under Azure AD B2C, not Azure AD)
3.Test the user flow
This error generally occurs because you still need to configure some application claims in the b2c directory user flow to allow complete access to the application.
You need to make sure that the right versions of the authentication are in the reply url (likely extension v2.0) and that the reply URL is configured in the application and in the code.
Please look to the documentation for the reply URL schema that you would need to follow: https://learn.microsoft.com/en-us/azure/active-directory-b2c/tutorial-register-applications?tabs=applications#register-a-web-application
If you still run into this issue let me know and I can reach out to the correct product team contacts, as sometimes this can happen due to breaking changes on our end.

Postman - how to obtain Azure Active Directory token using sign in form?

Is is possible to obtain an AAD token in Postman by letting the user to Sign In using the standard AAD sign in form?
I know how to obtain token using the request to AAD (grant_type = client_credentials) but such a token does not have a UPN (user identity).
I would like to somehow type in my credentials in Postman and get the token. So it is a manual interaction, the user(me) needs to manually sign in - the same way how ie. Visual Studio verifies your identity.
Postman now offers the ability to "Authorize using browser." You'll need to make changes to your AAD application to support it in addition to configuring Postman.
Configure your AAD application
Add a redirect URI to your AAD application for Postman to receive the authorization code. In the AAD Portal, navigate to your app registration, then to the "Authentication" tab, then add https://oauth.pstmn.io/v1/callback as a new redirect URI. This URI was provided by Postman when you check the ✅ Authorize using browser box (below) and is also documented on their website.
Configure Postman
You can set this up under "Authorization" for a single request, a folder of requests, or a Collection. Open the "Authorization" tab and select OAuth 2.0. Under the "Configure New Token" section, enter the following information:
Token Name: anything you want. I chose the name of the AAD application.
Grant Type: Authorization Code (With PKCE)
Callback URL: check the ✅ Authorize using browser box
Auth URL: copy this from the AAD portal under Overview > Endpoints (on top bar) > OAuth 2.0 authorization endpoint (v2). Mine looks like https://login.microsoftonline.com/<tenant>/oauth2/v2.0/authorize
Access token URL: copy this from the AAD portal under Overview > Endpoints (on top bar) > OAuth 2.0 token endpoint (v2). Mine looks like https://login.microsoftonline.com/<tenant>/oauth2/v2.0/token
Client ID: copy this from the AAD portal under Overview. It's also commonly referred to as an "Application ID" and is a GUID.
Client Secret: leave blank (not used by this grant type)
Code Challenge Method: SHA-256
Code Verifier: leave blank or provide your own
Scope: the scopes you're requesting in your token, separated by spaces
State: leave blank or provide a value such as a random GUID.
Client Authentication: Send as Basic Auth Header (not used by this grant type)
Refer to Postman's documentation on OAuth 2.0 options for more information.
Get a token
Click Get New Access Token to open the auth flow in your machine's default web browser. After authentication, it should redirect back to the Postman application and a new token will be created with the name you provided earlier for "Token Name." Select "Use Token" in the top-right corner of the popup to copy it into your current token. If the token expires and your requests start failing authorization (probably a 401 or 403 error), you can revisit this tab and get a new access token.
Occasionally, you may want to visit Current Token > Access Token > Manage Tokens > Delete > Expired tokens, otherwise you'll be inundated with nearly-identical tokens.
Postman cannot popup the sign in page as it only does HTTP requests. As you stated, it can do confidential client flows.
What you could do is hand-construct an auth request, sign in, and grab the auth code. Then take that auth code and drop it into the Postman authorization form, and let it hit the Azure AD token endpoint:
https://login.microsoftonline.com/common/oauth2/v2.0/token
The Azure AD protocol referene will be super helpful for you.
I think if you're wanting to quickly generate Access Tokens your best bet is to pick a framework/language and build a lightweight app that gets and logs tokens. Azure AD has a Python Flask sample for the v2 endpoint that takes 5 minutes to setup and could be converted to printing out access tokens. If you want to use v1, you can checkout the list of samples at the Azure AD developer guide.

When using Okta as an IdP with SP initiated workflow, login never leaves Okta portal

So I am trying to setup Okta as an identity provider, and I want to login to an application using the Service Provider initiated workflow. I've setup the template SAML 2.0 application in Okta and setup the entry point and SAML certificate on the Service provider. The Service Provider initiates the workflow just fine, a popup opens with the Okta login dialogue. But once the login is complete I am taken into the Okta portal with a list of my apps. What should be happening is a re-direct back to the Service Provider so that it can use the userID to login the user there.
I followed the instruction here for setting up the IdP https://support.okta.com/entries/23364161-Configuring-Okta-Template-SAML-2-0-application
Here is what my config in Okta looks like
Application Label: App Name
Force Authentication: no
Name ID format: EmailAddress
Recipient: https://serviceprovider.com/_saml/validate/okta/
Audience Restriction: https://serviceprovider.com/
authnContextClassRef: Password Protected Transport
Destination: https://serviceprovider.com/_saml/validate/okta/
Response: signed
Assertion: signed
Request: uncompressed
Default Relay State: Leave blank since we are only doing SP initiated workflow
Post Back URL: https://serviceprovider.com/_saml/validate/okta/
Attribute Statements: none
Group Name: leave blank
Group filter: leave blank
I don't see any errors in the Okta portal or in the Okta administration panel, so I can't figure out why it is not completing the workflow and re-directing back to the SP.
Is there a place in Okta to see any errors that might be getting thrown by the process?
Anyone know what might be up?
I had a similar problem a while back. In my case, the "Rquest" was set to "compressed". changing it to "uncompressed" solved the issue. But in your case I see it is already "uncompressed"...
However, try to contact OKTA's support - they can help you out.
The answer is different depending on the type of SAML HTTP BINDING used for the SAML Authentication Request.
For HTTP Redirect Bindings you need to set the Okta Request to "compressed".
For HTTP POST Bindings you need to set the Okta Request to "uncompressed".

Resources