Which Azure AD authentication flow is suitable for Progressive Web Apps (PWAs)?
Is the Implicit flow the only way?
If your Progressive Web App is developed only as a static single page website i.e., without any server-side code (like C#, python..) then you have below options
The implicit flow.
Authorization Code Flow with Proof Key for Code Exchange (PKCE)
If you have server-side(backend) code running for the dinamic website then,
OAuth 2 authorization code grant is an option that will be more
secure than implicit flow.
You can also use OAuth 2 on-behalf-of authentication flow as another
option.This flow is used when an application invokes a service or
web API, which in turn needs to call another service or web API.The
idea is to propagate the delegated user identity and permissions
through the request chain.
please refer MS documentation for more information.
Related
I have an existing ASP.NET Core API with its Swagger supporting JWT bearer token authentication from an AAD (mono-tenant).
This API supports both user and client credentials JWT tokens.
I am trying to create and use a logic app custom connector to use my API but I cannot find a way to make the client credentials authentication work.
It seems I can edit the swagger file to use the 'application' flow but it does not seems to be correctly supported.
securityDefinitions:
oauth2_auth:
type: oauth2
flow: application
tokenUrl: https://login.microsoftonline.com/xxxxxxx/oauth2/v2.0/token
scopes: {.default: .default}
Are client credentials supported from the logic app connector without custom logic in the logic app flow ? (I cannot find anything about supported scenarios in the docs)
In order to use the credentials in a standard connector, you need to switch to Active Directory OAuth. And then fill in the client credentials. If you are about to use Microsoft Graph, make sure to specify the Audience as well.
For more details, you could refer to this article.
I have a problem with consenting to my API. I have 2 apps in my tenant (Client, API). Client app is SPA and implicit flow is enabled and it calls API, so I added Client application's id into knownClientApplications in API application. For both applications multi-tenant is enabled.
But when I try to login in my SPA from different tenant I'm only asked for Client application consent and get an error that I don't have service principal for my API application.
What should be configured in order for this to consent implicitly to API application too?
I use MSAL.js library and Azure AD 2.0. Scope: https://mytenantname.onmicrosoft.com/myservicename/user_impersonation
For the SPA application to prompt consent combined with your API consents, your scope should be https://mytenantname.onmicrosoft.com/myservicename/.default.
You can read about ./default scope here.
If you need a sample to clarify this concept, I would suggest this one
I am working on a webapp, the Front-end is implemented in AngularJS which talks to back-end server by invoking REST API. The back-end is Java REST Server implemented using reslet framework deployed in Jetty.
Currently, when a user logs into a web app, a REST API is invoked which then goes to the Java REST server. The server then authenticates the user.
I want to implement SSO using SAML. So when a corporate user tries to login to the app, the user must be redirected to ADFS. If the user is successfully authenticated he must be allowed to login to the app.
I want to know how do I start? I have seen sam2-js library, however it seems to be for NodeJS based server. I am not quite sure if it can be used with AngularJS on frontend.
SSO with SAML involves browser redirects so the flow is between angular and ADFS.
There's no Java backend.
So Jetty is irrelevant.
SSO has nothing to do with REST. They are two different flows handled in two different ways.
SAML is not a suitable SSO protocol for angular. That's why you can't find any examples.
You need to use OpenID Connect with ADFS 4.0. ADAL is the way to go.
We have a SharePoint publishing site with anonymous access hosted on internet. As per the latest requirements, we need to implement user login (AzureAD, Microsoft personal and work accounts, and more) for some pages within the portal.
There are two approaches we have come up with:
Using msal.js file. Implementing login of user at client side itself and calling Partner Center Web API with user token to check the validity of the user plus performing required operations.
Create a Web API with with Microsoft.Owin.Security.OpenIdConnect nuget package at Web API end to implement login and also use it for doing out required operation of retrieving and modifying data from the backend.
Which approach may work best in our scenario?
Is there any other way to achieve this?
The difference between these two approaches is that they are using the different flows to integrate with the identity data provider.
The second approach that using the server-side code is using the authorization code grant flow which is a stand flow to interact with identity data provider.
The first approach that using the msal.js is using the implicit flow. is a simplified authorization code flow optimized for clients implemented in a browser using a scripting language such as JavaScript. In the implicit flow, instead of issuing the client an authorization code, the client is issued an access token directly.
More detail the flows using the OAuth 2.0 are defined in the OAuth 2.0 Authorization Framework.
I am building a cross-platform mobile app that interacts with a RESTful API, and I want to use OpenID Connect to authenticate my users. I will be building my own OpenID Connect provider server.
OpenID.net claims that:
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
However, I can't find any documentation explaining how to actually authenticate for a mobile app client.
This StackExchange answer makes it clear that OpenID Connect does not support the "resource owner password-based grant" flow or the "client credentials" flow.
That just leaves the "authorization code" flow (normally used by server-side apps) and the "implicit grant" flow (normally used by client-side apps). Both of these seem to rely on redirecting the user to the provider's authorisation endpoint, and having the provider redirect back to the client URL. I don't see how this can apply to a mobile app.
Can anyone explain to me (or even better, point me at a tutorial or some example code) which explains how to do this?
Update
To clarify: OpenID Connect relies on the client redirecting the user to the Authorization Endpoint, and then the provider redirecting the user back to the client. In the case where the client isn't a web app, how can this work?
Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.
So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.
A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.
Please also note that the use of the "Implicit Grant" flow is now highly discouraged.
I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.
This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).
There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.
Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.
https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472
The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:
Google will not vend any client_secret for an oAuth client that is typed "Android"
Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"
Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server:
https://developers.google.com/identity/sign-in/android/backend-auth
This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.
Check out MITREid project on github:
MITREid Connect
This project contains an OpenID Connect reference implementation in
Java on the Spring platform, including a functioning server library,
deployable server package, client (RP) library, and general utility
libraries. The server can be used as an OpenID Connect Identity
Provider as well as a general-purpose OAuth 2.0 Authorization Server.