Wonder if someone can clarify this for me
I'm using ADAL js to log in an angular7 application via the implicit flow.
This works by sending the response_type=id_token
What happens with this response type is that the Authorization endpoint is hit and I should get back an ID token
However I appear to be getting a bearer token back, Azure microsoft login redirects me to http://localhost:4200/#access_token=xxxxxxxx&token_type=Bearer
What I was expecting was this token returned would be an ID Token not a bearer token, it does behave correctly like a Bearer token when I call the back end APIs.
ADAL.js doesn't appear to let me request "id_token token", which is the following:
I'm sorry I started reading the spec as it's confused my understanding of an application that's working, but i'd certainly appreciate if someone could shed a little light on what azure actually does with it's implicit flow, it only mentions id_token in the docs and make no reference to 'id_token token' response type
if anything, Azure AD appears to be more inline with reponse_type=token
tnx in advance,
Brian
Azure AD V2.0 Endpoint
Microsoft Docs: v2.0 Protocols - SPAs using the implicit flow
It clearly mentions that for OpenId Connect,
request must include response_type=id_token (which you're already sending)
scope=openid which was probably missing and got resolved after implementing the flow using MSAL library (as described by #brianbruff in comments).
Also, Allow Implicit Flow should be enabled for App registration.
Sample request from docs
// Line breaks for legibility only
https://login.microsoftonline.com/{tenant}/oauth2/v2.0/authorize?
client_id=6731de76-14a6-49ae-97bc-6eba6914391e
&response_type=id_token
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&scope=openid
&response_mode=fragment
&state=12345
&nonce=678910
Azure AD V1.0 Endpoint
Microsoft Docs: Understanding the OAuth2 implicit grant flow in Azure Active Directory (AD)
Even here, documentation clearly says that id_token can be obtained when using OpenID Connect.
I must say though, that I am not completely sure on recommended/correct implementation to get id_token in case of implicit grant flow with v1.0 yet. (At least #brianbruff is able to use v2.0 and resolve his problem.)
I see that another Microsoft Docs link for OpenID connect with v1.0 (but not Implicit grant flow) mentions the usage of scope=openid. Although, right at the bottom of this page I see open issues where users contradict the documentation in some way and have given feedback specifically for Implicit Grant flow.
Issue 17140
Issue 19382
Related
I'm used to working with ADFS for a long time already and recenlty I was asked to do a proof of concept with Oauth2 on ADFS. Struggling through terminology I managed to set most things up, but still I do have some unanswered questions. Hope someone can shed some light on these...
For SAML / WS-Fed relying parties, it is possible to set custom web content, using Set-AdfsRelyingPartyWebContent. Is this also possible for web api relying parties created in an application group?
Would it be possible to add claims to a client authenticated with client_id / client_secret (server application in ADFS terms) when using the client credentials grant flow?
Even after setting the 'IssueOAuthRefreshTokensTo' 'AllDevices' on the web api application, I still don't receive refresh tokens. What am I missing here?
When posting a token issued by our ADFS on e.g. jwt.io I receive an 'signature validation' error. How can we resolve that?
We would like to set an audience for the access tokens, so applications can use the audience instead of using the appid to verify if they can consume the token. Can we modify the audience?
What does add-adfsclient do? Does it create a client_id, which can then be linked to a relying party (with Grant-AdfsApplicationPermission), thus enabling OAuth2 for an existing relying party?
When configuring a ad user principal for a server application and use 'password' as grant_type with the client credentials grant flow, I cannot seem to find the correct syntax, as ADFS always give the error 'MSIS9622: Client authentication failed. Please verify the credential provided for client authentication is valid.'. I have used the syntax 'user#fqdn' for the username.
Thanks you for helping me out here!
Let me try and work through these.
In ADFS, OIDC applications and WS-Fed / SAML RP are completely different. You can't mix and match.
jwt.io has a signature error because it doesn't know the .well-known endpoint to get the key. Refer this.
To get extra claims you need to add an API as that is the only place for claims rules.
To get a refresh token, you need a scope of "offline_access".
For resource owner password, user name and password are separate fields. Refer here.
Feel free to ask more questions. Just expand your question.
Also, samples here. Look at the menu on the LHS.
Update
What do you mean by "can modify web content on a per relying party basis"?
Re. jwt.io, read this.
For refresh tokens, read this. It seems ADFS doesn't follow the spec here.
after trial and error it seems to me that Google OIDC does not support the code flow without supplying the client secret:
https://developers.google.com/identity/protocols/oauth2/native-app#exchange-authorization-code
According to the latest best practices for SPAs (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-security-topics-13), code flow + PKCE is the recommended way to handle authentication. Is anyone aware of any trick required to make Google's code flow accept the code_challenge rather than the client_secret? Perhaps a dummy secret?
As of August 2020 the best practices document cited is still in draft and being activly updated - head revision here: https://datatracker.ietf.org/doc/draft-ietf-oauth-security-topics/. Googles' OAuth2 implementation has not yet applied the "work in progress" recomendation of PKCE being applied to web applications. SPAs are still directed to use the implicit flow in Googles' online documentation: https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow).
The standard for PKCE (https://www.rfc-editor.org/rfc/rfc7636) details that it was developed as a mitigation for authorisation code interception attacks found on mobile platforms and was originally recommended for implementation by native clients. Google's documentation for "Mobile and Desktop apps" does direct developers to use a PKCE Authorization Code flow. Clients using Google Android, iOS or windows store credential types with PKCE may omit the client_secret (see the note on the refresh token parameter table - and confirmed by Cristiano).
It is now recognised that PKCE eliminates the need for any public clients to store a client secret, and as such can be used to deprecate the implicit flow which always had the flaw of including returned access and identity tokens in a redirect URI. https://developer.okta.com/blog/2019/05/01/is-the-oauth-implicit-flow-dead.
The draft IETF document states in section 2.1.1 that this recognition is likely to become a published standard.
Hopefully Google will update its implementation to remove the requirement for a client_secret for a PKCE token request when the best practices becomes accepted. In the meantime it seems we have no choice but to continue writing SPAs using the implicit flow.
A good alternative IMHO consists in using Keycloak as IDP and then adding Google to the delegate identity providers of your Keycloak instance (and then Facebook and then any other idp if required). Keycloak implements the PKCE flow or whatever flow in the Oauth 2 RFCs in a reliable way. That means you need a hosted instance of Keycloak though.
Well, I'm using openId Connect authorization code with pkce without using client_secret in an android app using this lib: https://github.com/openid/AppAuth-Android.
I just had to ensure that the custom scheme was set using the app's package name from the manifest and use it to register the android credential on google console.
I configured Hybrid mode on a customer's Exchange 2016. Now users' mailboxes are exposed on the Microsoft Graph API using the individual consent flow (authorization code Oauth2 flow).
Getting an admin consent with a client credentials flow seems to work : a token is retreived on the Microsoft endpoint, the payload is correct (right scopes), but it triggers an "unknown error" when using it to get a mailbox content through the Microsoft Graph API. The same token does work to get directory information (meaning the token is valid at some point).
Is Hybrid mode compatible with the Client Credentials flow ? Is there any parameters to configure in Exchange to enable this flow ?
I stumbled upon the same issue some time ago. Just let it slide, as I thought it was some wrong configuration on the Exchange side.
If you inspect both tokens you'll see that the sid is missing on the Client Credentials token, I think exchange needs some sort of on-premise user id inside the token to work. I'm not sure if this flow is supported since I cannot find anything about this topic on their documentation websites.
I just found a totally related question, check out https://stackoverflow.com/a/56108226/639153 for a complete answer.
The issue is actually somewhere else - Exchange doesn't seem to support client_credentials flow. You can, however force it via following PowerShell (make sure to restart your IIS after applying):
$apps = Get-PartnerApplication
# Microsoft Graph is 2nd item in the array, if you are unsure, list the items by calling $apps first
$apps[1] | Set-PartnerApplication -AppOnlyPermissions $apps[1].ActAsPermissions
The full explanation can be found here: https://blog.thenetw.org/2019/05/13/using-client_credentials-with-microsoft-graph-in-hybrid-exchange-setup/
Hello kind people of the internet.
Does Google OAuth2.0 support an OAuth-flow for a Resource Owner Password Credential Flow?
...and if so, then:
A.) can this type of OAuth flow be tested on the Google OAuth2 Playground?
B.) are there any examples of the "Resource Owner Password Credential Flow" with Google OAuth2.0 and the Google APIs?
Per an OAuth presentation recently in Oslo NDC 2013, this subject flow apparently skips the authorization end point all together and directly talks to the token end point of the OAuth2 server. The request syntax incantation would supposedly look something like this:
grant_type=password&
scope=resource&
user_name=owner&
password=password&
My understanding is the Resource Owner Password Credential Flow is for trusted applications in a back-end enterprise type of situations (where a name-password pair could be securely stored).
This particular OAuth flow would require no end-user consent interaction (no pop-up of a browser to Accept, then get a returned authorization-code, etc). In this subject flow the access & refresh token are directly returned, again: with no end-user interaction (albeit after an entry of a username-password).
Looking through the Google OAuth documentation ( link to Google OAuth2 docs ) there does not seem to be any mention of anything resembling Resource Password Credential Flow, but not sure that necessarily means it is explicitly not supported by Google.
Any help or advice would be much appreciated.
thanks in advance
Dear kind internet person,
it is true that Resource Owner Password Credential Flow is not supported on Google but google suggests you use the Installed Application Flow, which is described in: https://developers.google.com/accounts/docs/OAuth2InstalledApp.
You would need to create an Installed Application in the Google Console (https://code.google.com/apis/console), when you do that you can fetch the client_id and build a GET request with the parameters, which would look like so:
https://accounts.google.com/o/oauth2/auth\?
scope\=<scope>\&
redirect_uri\=urn:ietf:wg:oauth:2.0:oob\&
response_type\=code\&
client_id\=<client_id fetched from google console>
You would construct this URL and navigate to it on your browser, allow access for the app and google would give you what I believe is a code which you can use to get credentials. You can use those credentials to get an access token and refresh it, and this credentials is permanent. There's a good example of that on github. Note that you only need to get those credentials manually once, and then you save those credentials somewhere and keep using them to get/refresh tokens.
Hope this helps!
As far as I know, No. The OAuth 2.0 stuff is for Google accounts, for which Google does authentication.
So I've got OpenID+OAuth hybrid working with DotNetOpenAuth when connecting to google. It gives me back a Authorized token so I need to exchange it for an access token.
I seem to be coming in about midway through a normal OAuth workflow in DotNetOpenAuth. I also seem to be missing somethings that DotNetOpenAuth wants like the the token secret and verifier. However according to the graph here I shouldn't need them.
Any ideas how to easily swap the auth token for an access token with DotNetOpenAuth?
Since you're talking about the OpenID+OAuth hybrid I expect you're writing a web app (as opposed to an installed app). DotNetOpenAuth should only be asking you for a verifier code if you're using the DesktopConsumer class, which is inappropriate for you. Use the WebConsumer class instead and the verifier will be taken care of for you. Swapping the request token for an access token will be automatic as you call the simple methods on WebConsumer, I hope.
As for the token secret, all token secrets are managed by your implementation of ITokenManager, which will save and retrieve token secrets on demand within your database.