I'm using an Azure B2C Tenant which has some users. I created an application and in the authentication I choose web. I deselected the implicit grant flow because I was getting the warning This app has implicit grant settings enabled. If you are using any of these URIs in a SPA with MSAL.js 2.0, you should migrate URIs. I selected Local only and no other provider. I also have a Sing In User flow. I could not even see the login page from my C# ASP.NET application with those settings. So I selected the implicit flow. That solved the problem and I can see the login page and can login.
My question is why should I need am implicit flow for a web authentication.
If you're using the Microsoft Identity Web authentication library or one of the Microsoft Identity Web project templates, then it passes response_type=code id_token in the authorization request, which represents the hybrid flow.
This is why you must select the "ID tokens" settings for the application registration.
You don't need implicit flow unless you are using older versions of MSAL i.e., MSAL1.XXX version.
The latest version of MSAL.js i.e., MSAL 2.XXX version only works with
the authorization code flow with PKCE instead of implicit flow . So
you need to implement PKCE flow instead of implicit Grand.
If you are using latest version of MSAL please don't use Access_token and id_token settings which will enable implicit flow.
Related
We are trying to build application for Mobile and web
react-native and react js respectively.
As we see legacy spring-security-oauth is deprecated, we would like to use spring authorization server 5 project
Do this authorization server project supports Password Grant, as we have challenges in doing Authorization code grant for custom login Authentication like biometric
The Spring Authorization Server does not support authorization grant type PASSWORD. This project is mainly focused to deliver the Authorization server as per the latest OAuth 2.0 security practices in which the use of Resource Owner Password Credentials grant is disallowed.
I'm having an Angular application that performs user authentication via Microsoft account. For this, I'm using the MSAL JS library which does work fine to authenticate the user. But we have the requirement where our backend server requires to call Microsoft Graph APIs. Now the issue is that the MSAL library returns access_token which has got a life span of 1 hour and so it can not be used once it is expired from our backend server.
So I'm looking for a way where I can get an authorization code, which can be exchanged from our back end server to get the access token and refresh token. And as we've got the refresh token as well, we can refresh the access token whenever it gets expired considering a refresh token is still valid.
I'm not sure if this is possible via the MSAL library or not, or if there is any other alternative available for SPA to support the case, I've described above.
It is possible with MSAL.js 2.0 which is a drop-in replacement for MSAL.js 1.x and supports the authorization code flow for Single page applications. With MSAL.js 2.0 you can use the authorization flow with PKCE and refresh tokens in the Microsoft identity platform to keep users signed in while third-party cookies are blocked.
Read more here:
https://learn.microsoft.com/en-us/azure/active-directory/develop/tutorial-v2-javascript-auth-code
https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-implicit-grant-flow
https://learn.microsoft.com/en-us/azure/active-directory/develop/reference-third-party-cookies-spas
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 am using Thinktecture IdentityServer v2, the Relying Party token type is set to none. The code runs fine with this setting.
I am looking to use JWT tokens so I have a common interface from my MVC app to the API, and also from phone/tab app clients to the API.
When I set the token type to JWT, I sign in on IdentityServer then it throws the following error:
ID4014: A SecurityTokenHandler is not registered to read security token ('BinarySecurityToken', 'http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-wssecurity-secext-1.0.xsd').
I created a standard MVC app and had set the Authentication to Organizational Accounts -> On premise, and had set On-Premises Authority to the IdentityServer metadata url.
I plan to call WCF from the MVC app (and perhaps even javascript code on other platforms).
So far I have installed the specific JWT handler Update-Package System.IdentityModel.Tokens.Jwt -Version 3.0.2 (v4.0.0 has an issue apparently with Thinktecture IdentityServer v2) and then set the web.config to include:
However I then get a new exception when logging in:
Jwt10315: Signature validation failed. Keys tried: 'No non-null SecurityKeys were found'.
jwt: '{"typ":"JWT","alg":"RS256","x5t":"_rKoogN25ibGWZGC94xaed9g7FE"}.{"iss":"http://identityserver.v2.thinktecture.com/test","aud":"https://localhost:44302/","nbf":1419269158,"exp":1419305158,"nameid":"user","unique_name":"user","authmethod":"http://schemas.microsoft.com/ws/2008/06/identity/authenticationmethod/password","auth_time":"2014-12-22T17:21:43.655Z"}'
How can I have the MVC app so it can consume JWT tokens?
Why do you want to use JWT? Especially when you want to call WCF at some later point - JWT is the wrong choice. WCF works best with SAML tokens.
We're building a new app that requires access to specific customer data, and OAuth appears to be absolutely perfect for our requirements - long-lived access tokens, ability to grant access to specific resources or scopes, and so on. We are not looking for 'log in with Facebook' type capabilities here; we want to expose a single, specific OAuth authentication server based on our existing customer login database, and allow web and native apps to authenticate users via this endpoint.
I've been looking at the DotNetOpenAuth code samples, and it appears that all of the OAuth 2 examples use OpenID to perform the initial authentication and then use OAuth to actually authorise access to resources.
My understanding is that you can use a 'no-op authorisation' to perform the initial authentication, allowing you to use OAuth2 for the whole process; since we don't want to support federated authentication, OpenID doesn't actually offer anything, and so I'd rather stick to a single protocol for simplicity if possible.
Is there a good example anywhere of a pure OAuth2 authentication server built using .NET? Have I misunderstood the example code supplied with DotNetOpenAuth? Or is OpenID still required for the initial authentication phase?
There's no coupled relation between OAuth2.0 and OpenId.
You can implement your custom login strategy in your OAuth2.0 implementation.
Since you gonna be the "Resource Owner"(as far as I understood your application owns the user base), you can simply replace in the DNOA authorization server sample the openid login with the standard asp.net login.
OAuth2.0 protocol simply needs to verify a user identity in order to emit an access token: how that identity will be verified is totally up to you.