I am implementing a REST Web API for a service that will be hosted on Windows now (and on Linux in the future).
We are going to support custom credentials + token/refresh token using OAuth 2.0 and OIDC (via Identity Server 4), but we want to support also Windows authentication to allow integration with Active Driectory.
For clients which use windows authentication, is it better to authenticate once and get token/refresh token mechanism (as we do for credentials authentication) or is it better to authenticate each single request?
The latter option might be less performant as it needs to go through the challange every time?
My personal feeling is that if you're having identityserver4 in play already and the fact you've stated you will host the API on Linux in future that you should handle the AD integration in your identity server and have your API only worry about access tokens issued by said service.
I'd then recommend using ADFS (recent versions support OIDC out of the box) for the actual authentication of AD users and have your identity server act as an authentication gateway. If configured correctly you can achieve true SSO (i.e. the user is not required to re-enter their domain credentials) for any user already signed into the domain on their PC.
This just covers authentication however - how will you be doing authorization within this API?
Related
I'm creating a centralized authentication system for multiple mobile applications. Its architecture is based on the OpenID Connect flow through the use of OAuth2.0 with IdentityServer4 on ASP.NET Core Identity.
I have researched a lot and in the main implementations with the Authorization Code Flow observed there is always the redirection of the user from the mobile app UI to the server web views, to allow the management of its profile.
This is very uncomfortable, because it significantly compromises the UX. I would like the user to be able to register and authenticate himself directly from the app interface without any redirection that involves opening a browser. Is there a way to do this with only API calls, from the client backend to the centralized authorization server?
You can use the Resource Owner Password Credentials grant type where you can pass the user credentials to the token endpoint and receive an access token. But usage of the ROPC grant type is highly discouraged as you can read in this blog post from Scott Brady, one of the creators of Identity Server.
What I can propose to you is to use Authorization Code flow to login the user and get access token for them, and then creating your custom API endpoints on identity server for user management. More on custom api endpoints here
I'm trying to get information how to authenticate and authorize a user from a backend WCF service using OpenID Connect configuration rather than using a client application (like Angular / .Net MVC web application).
Can this be achieved using "Authorization Code Flow"?
If yes, could one please guide me, how this can be achieved as we will not be able to configure the re-direction URL for a backend service to get the access token.
If not, could one please tell me how this can be achieved? I did read that this can be achieved by back channel communication (i.e. https://openid.net/specs/openid-connect-backchannel-1_0.html. If one can help me with the tutorial document that is available in internet that would be really helpful.
The link you mention is about back-channel logout: a communication from your OpenID provider toward your backend to notify your backend of a user ending her/his session at the OpenID provider. I do not see how this could be used to authenticate a user.
It feels somewhat odd that you are trying to authenticate a user from a backend service. The whole idea behind OAuth and OpenID is to pass a credential allow with your request to the backend. The backend must verify that credential but should not involve in gathering and issuing that credential, it should rely on a trusted party (the OpenID provider) to issue those credentials.
I am trying to develop a concept to support multiple authentication methods in an ASP.NET core server environment which should support both Windows (WPF) clients as well as Web clients (Angular). Users should be able to login using three methods:
using username & password, which is checked against database of valid logins
using Windows authentication (i.e. the currently logged in user). This may require user PC and server to be on the same network/domain
using selected external authentication providers, such as Google
Users should have individual rights (claims), which either derive from their individual profile or group membership (e.g. in case of AD).
I am still at the concept phase, trying to figure out the basics here, so no code has been written yet.
My thinking is as follows:
users logging in using username & password receive a token (JWT) of some sort which then authorizes them to access protected/restricted calls.
users logging in using their Windows identity would basically receive the same token
users logging in via external auth-providers would receive the external token from the provider and use that to login and also receive an token from the server
regardless of 1-3, users end up with a server-issued token that gives them access to restricted features
Is that a common/correct approach for mixed authentication? If so, how would this be implemented on the ASP.NET core server side?
I am trialling Azure B2C Customer Preview and have configured a new application, set up policies e.t.c and I now want to write some integration tests that use a non-interactive flow to connect and interact with my protected WebApi services.
However, I have just read the following quote:
Daemons/Server Side Apps
Apps that contain long running processes or that operate without the
presence of a user also need a way to access secured resources, such
as Web APIs. These apps can authenticate and get tokens using the
app's identity (rather than a user's delegated identity) using the
OAuth 2.0 client credentials flow.
This flow is not currently supported by Azure AD B2C - which is to say
that apps can only get tokens after an interactive user flow has
occurred. The client credentials flow will be added in the near
future.
from this link which suggests that what I am trying to do is not yet possible. Can anyone from the Azure team tell me whether this information is up to date, and better yet a rough timescale for delivery on this feature?
I've seen a lot of questions regarding OAuth and using it to secure APIs using an external trusted provider.
However, in our organization, we have an existing ASP.NET MVC web application which contains a custom membership provider for authenticating users to use the web application. We are now developing an API (which will be accessed externally) which allows users of the API develop their own clients.
I am looking into different ways to secure the API without passing user credentials. The API will force HTTPS, but the security team does not want user credentials stored on the client systems. I have considered, a token based approach -- but most posts I have read here seem to suggest OAuth. Would the preferable route be some sort of OAuth implementation? And if so, how do I authenticate internal users who are not registered with a trusted provider?
Thanks!
One approach can be to use OAuth token created Microsoft ACS.
If each client user needs to be authenticated, you can use Microsoft ACS to create a trust relationship between you and the client organization (Id Provider) or even other Id providers such as Facebook / Google etc.
Alternatively you can also use service identities for each API client (assuming that each user does not need to authenticated) The clients gets a unique clientId and Secret created by your organization, that you can revoke when needed. The client requests a OAuth2 (JWT) token from ACS and send the token on each API calll. The API validates the token using standard OWIN library for JWT tokens.