I'm using Identity Server 4 to authenticate users with WebAuthN (https://w3c.github.io/webauthn/).
I have multiple clients that that hit an api client. My api client is responsible for deciding which auth provider to use, passing data (server to server, server to external api) and orchestrating the auth process.
One auth provider we are using that we own is identity server 4 and this is where we are implementing WebAuthN.
I'm not sure which is the recommended way to implement this in Identity Server 4. I'm down to 2 options
Create an API endpoint on identity server to authenticate to users credential
Create an extension grant type and call the TokenEndpoint API using the new grant type (my extension grant type would be a mix of the built in Hybrid grant type followed by the WebAuthN code).
Are both ways valid from a security standpoint (not opening up a hole) and fit with ID4 or is there another way?
I've recently done some work on implementing this, but for second-factor only at this point.
Long story short, it needs to run in the context of the end user's browser (given that it's a JavaScript API) so really it needs to be built into the sign in flow via the authorize endpoint.
For example (assuming no local client or IDP sessions already exist):
User visits client application
Client redirects to authorize endpoint
Authorize endpoint redirects to interactive authentication UI which then decides what method to use
Do the WebAuthn challenge, validate the result and establish a session cookie
Redirect back to authorize endpoint
Issue tokens and redirect back to client
You'll also need to provide a way for users to register their authenticators. The resulting credentials are tied to the site origin so this must be done within your identityserver4 implementation - the same application that will be doing the challenging.
Related
I have been looking into using an identity provider (IDP) to provide user authentication for a Windows Forms client. The user credentials will be hosted by Auth0. After creating a trial account with Auth0 I have downloaded a sample C# Windows Forms client application that can be used to authenticate to the Auth0 IDP using OpenID Connect ("OIDC"). The WinForms sample application pops up a web browser component, displays the Auth0 login screen, I login to the Auth0 IDP (having setup some test credentials in Auth0) and the WinForms application then is sent an authentication token. All well and good, and if I try to login a second time I no longer need to enter my credentials.
However... the company that I will be fetching authentication data from in production would like to use SAML. Is there any way to do this? Based on what I have read, SAML needs a "Service Provider" that will receive credentials from the IDP. The Service Provider is (typically?) a web site. That does not seem to match very well with what I am trying to do (authenticate a windows client). Is there any way of using SAML to do essentially what I have done using OIDC (fetch authentication information for a user from an IDP)? Would I need to develop a separate Service Provider component for this?
Sounds like what you've done so far is fine architecturally:
A modern desktop app following OIDC standards
This puts you in a good position architecturally, where:
Your app gets tokens from Auth0 using OIDC
Auth0 can reach out and do federated authentication with other standards based identity providers, which could be SAML, OIDC, WS-Federation or anything else
This can be done without changing any code in your app - and your app does not need to understand SAML
Feels like you need to set up a federated connection from Auth0 to the SAML Service Provider, and most commonly this involves these steps:
You give the partner your Entity Id and Response URL, to post tokens to
They give you am Entity Id, Public Key Certificate and request URL
You configure rules around account linking, so that users can be matched between their system and yours
There are prerequisites though, and the external identity provider needs to be SAML 2.0 compliant. My Federated Logins Article may help you to understand the general concepts, though I do not drill into SAML details here.
I am currently following this user guide for adding a custom policy to my B2C sign up process
I have created the API and configured the various XML files. I can generate a token to access the API via the implict flow.
The API is secured under the app service with Azure Active Directory authentication.
The page linked to describes how to add basic authentication and a client ID / secret, which is a Client Credentials flow, so I was trying to test this in postman
However, having failed to get it to work I went looking and found a variety of posts stating implict credentials are not supported by Azure B2C?
If that is the case I'm puzzled how it is I'm supposed to ensure the claims of the API I am calling to carry out the business logic can be accessed by the custom policy?
My API is hosted on Azure in the same subscription. I can generate tokens for this API fine to use within my native / client app.
Please could someone advise how I should go about testing access to this API from a B2C context via Postman?
The page linked to describes how to add basic authentication and a client ID / secret, which is a Client Credentials flow, so I was trying to test this in postman
To be exact, it should not be called Client Credentials, because it isn't it.
It's just HTTP Basic authentication.
You are adding an alternative authentication method to your API in that case.
The fact that B2C does not support client credentials auth does not matter here.
What matters is that you have enabled AAD authentication on App Service.
This will block the calls that try to use Basic auth against your API.
Here are a couple options that you can do:
Disable authentication on the App Service and implement the two alternative authentication methods in your API code
Allow anonymous calls through from App Service auth and implement Basic auth for unauthenticated requests in your API code
As for testing from Postman, it should then be the same as testing any API supporting Basic authentication.
You don't authenticate against B2C, so there is nothing special about it.
I have IdentityServer 4 and an MVC application that gets the identity from IdentityServer. Everything works fine.
My question is why do I have to login on IdentityServer and not on the MVC project?
I would prefer to stay in my MVC project, instead of being redirected to IdentityServer and back to my MVC project. Can somebody please explain why it has to work like that?
The redirects takes time, are not instant, and creates a lot of traffic that is unnecessary. I understand this redirection when there is an external provider like Facebook, but in my case I think it is useless.
And is it possible with IdentityServer 4 to login/create user on the Mvc app and call the api functions from IS4 server for Login/Create User?
The behavior you don't like is just a protocol. The protocol called OpenId Connect. And Identity Server just implements that protocol. The idea is that only Identity Provider itself can authenticate a user secure enough. There is a workaround called Resource Owner password flow or grant, where you ask a user for credentials in you client app and then transfer that credentials to IdP. The flow is not recommended for general use, but you may use it whenever you own both client app and IdP. One more possible solution for you (in case you own the only app and by some, really strange, reason would like to use Identity Server as an IdP) is to host Identity Server inside of your app. Then using IdentityServerTools helper class you can access the IdSrv internals without network calls.You can find much more information on both these approaches in Identity Server Docs and OpenId Connect specification.
New to Azure AD... So please don't be too harsh if this is off target. :-)
Technology Stack - Latest Angular 2 with C# Middle tier and latest .Net Framework.
Ideally, What we want to do is use Azure AD B2C to store user credentials and to do the authentication - but we want our 'own' forms on our site to do the login Forms capture and logging - then pass the credentials through an API (REST?) Call (using MS Graph SDK?) to Azure AD B2C and then check the call return for the Authorization content message.
Couple of reasons - control of the application flow, Logging and the "flickering of the URL" (i.e. going from our site URL to login.microsoft... URL and then back to our sites URL).
Is this doable without doing a hack?
Thank you in advance for your help and patience!
You are looking for the "Resource Owner Password Credentials".
This is not currently supported for Azure AD B2C, but you can give user feedback to the B2C team that you want this through the Azure Feedback Forum: Add support for Resource Owner Password Credentials flow in Azure AD B2C and headless authentication in Microsoft Authentication Library
You should also see updates at that location if and when they implement this feature.
The resource owner password credentials flow is now in preview.
In Azure Active Directory (Azure AD) B2C, the following options are
supported:
Native Client: User interaction during authentication happens when
code runs on a user-side device. The device can be a mobile
application that's running in a native operating system, such as
Android, or running in a browser, such as JavaScript.
Public client flow: Only user credentials, gathered by an application, are sent in
the API call. The credentials of the application are not sent.
Add new claims: The ID token contents can be changed to add new claims.
The following flows are not supported:
Server-to-server: The identity protection system needs a reliable IP
address gathered from the caller (the native client) as part of the
interaction. In a server-side API call, only the server’s IP address
is used. If a dynamic threshold of failed authentications is exceeded,
the identity protection system may identify a repeated IP address as
an attacker.
Confidential client flow: The application client ID is
validated, but the application secret is not validated.
From here.
Note that one disadvantage of doing what you're requesting is precisely that you can do "login forms capture and logging", so your application has a chance to see the credentials and perhaps take copies of them; thus your users have to trust you to behave.
The normal web-based flow means that your application doesn't need to be trusted; it never even sees the password at all.
My current setup is a fairly simple one. I am running Identity Server 3 which is used to provide oauth access tokens which can be used against and a number of our web api endpoints. The identity server has custom user service which authenticates requests against a custom user table in our sql database.
We have a new 3rd party software provider, this provider requires that our users (staff in our call centre) logon to their application via a proprietary login, not against our existing user accounts. We have built an api for this 3rd party which they required for their integration, as with the rest of our api's this is secured using oauth bearer tokens via identity server.
Our staff are all locally logged on to an active directory domain. Is it possible to configure identity server to issues auth tokens for a user who is already authenticated against active directory? I like to achieve this without prompting the user for their credentials again.
I've read around and at this point I'm very lost as to the correct approach, some form of federation seems appropriate, but I couldn’t find a reasonable introduction / walkthrough to help me get started.
What is an appropriate approach and are they any relatively easy to consume primers on the subject?
Yes, you should be able to make it work. The samples contain a windows auth provider. Using this, your identity server would authenticate people in without prompting for a password. Once authenticated, it would then issue tokens same as any other auth. You may need to a bit of experimenting to get it working, but from what you've said it should work in your situation.