I have to implement single sign on existing webforms application.
Before OpenID we were using OWIN OAuth library to have single sign on for external logins such as Facebook or google.
I have found that now OpenID is used for external logins but I also found that Identity Server 4 is also used as middle ware on top of OpenID to generate and verify tokens.
Why one would create a complete token verification system (Identity Server 4) if he can use google and facebook authentication using OpenID?
I want that my webform application should include external logins but I am confused what should I use (Identity Server 4 or OpenID connect)?
If OpenID then please let me know that this article is the right path to get start.
IdentityServer4 is simply an implementation of the OpenID Connect Provider specs (Basic OP, Implicit OP, Hybrid OP, Config OP) that allows you to build your own identity service.
Unless you want to build your own identity provider/secure token service then you do not need to use it. If you just want to consume 3rd party OpenID Connect providers like Google and Facebook then you can implement that using the Azure AD guide you linked to.
Related
I have two web applications that I've worked on in ASP.net Web API for a client. The two applications are hosted on the same domain, but in different virtual directories.
Each application has a data source with information about authorized users. I've been asked to set up a separate app that will allow a user to log in and issue an OAuth bearer token that can be used to access each web application.
I have the Owin stuff set up in one of my two apps with something of a boilerplate setup and it automagically makes the tokens work for me, but that's only within a single web application.
I have a general idea of how the OAuth tokens work: a user is authenticated and they receive a token that contains a user ID, a time stamp, and a cryptographic signature that says that the token came from my client's server and not somewhere else, and the Web API framework automatically checks that token for me when I decorate my API endpoints with the [Authorize] attribute.
I want to know how I can set this up so that the token is issued by one web app and consumed by another. I know that at a minimum, I need to make the two web apps work with the same key pair for the cryptographic signatures.
Can I please get some direction about how to make this happen?
So I'm trying to use Google Sign In and Sign in with Apple in my native mobile app which also communicates with my own backend server. I think I have the grasp of the OAuth2 flow and the concept of ID Tokens behind OpenID Connect. The only doubt I have is if I can/should use the access/refresh token pair to authorize access to my own endpoints? On apple's documentation this isn't clearly stated and on Google's site they mention you CAN use it to access Google APIs, but nowhere have I found you could use it for your own backend server. If not, how should this be approached (generating my own access/refresh token pair after validating the the authorization server's ID Token?)
Note that I only need to authenticate my users via these platforms, I don't want access to other Google APIs (for now).
TL;DR: Can I use Apple's/Google's access/refresh token pair to authorize access to my own backend's endpoints or should I generate my own/do something else?
You can use the tokens provided to you, but often you soon or later will want to customize what they contain and then introducing your own local provider can be a solution. So that your internal services trusts the tokens from your own service an your auth server trusts the tokens from Apple/Google.
The second problem is that your internal systems might need to trust multiple token issuers. In my experience is to internally only trust one token service and not multiple, even if this is not a hard requirement.
I am currently building an identity server with Duende IdentityServer v6.1. I separated the identity server from my API into two different subdomains. People can register an account with the IdentityServer, but I also want some registration information to be saved to the API-database. So I want IdentityServer to be able to communicate to the API. Is this possible and if so, how?
It is described in the documentation of IdentityServer: https://docs.duendesoftware.com/identityserver/v6/tokens/internal/
I have an ASP.NET Core Web API app and to secure it, I've implemented JWT Bearer authentication. The next step is managing user access and issuingJWT token.
Initially I considered using Azure AD B2C but it doesn't seem to support my business requirements. So I'm now considering using Identity Server 4.
Is Identity Server 4 run as a completely separate application? Also, am I understanding it correctly that it is used as:
A web interface for users to register and login
Also a web app with API that issues the JWT token
In other words, does Identity Server 4 "act" as my own Azure AD B2C service?
IdentityServer 4 is a Web app (Login & Logout pages) with an API that implements the OAuth 2.0 and OpenID Connect specifications. The samples provide a simple user login and logout views that you can change to your liking.
Regarding the user registration process, you may add that to your IdentityServer4 implementation or have that as a separate web application.
Similarities to Azure AD B2C
This came from another blog article
Authorization
Azure AD B2C allows you to model user roles as membership in groups
that you define. You can’t currently get a token containing those
claims, but you can use the Azure AD Graph API as a workaround to
retrieve the group memberships, and use them in authorization checks
inside your application. It’s a little tricky right now, but
improvements to this are on the B2C team’s roadmap.
API Authentication
Azure AD B2C can provide tokens for authenticating API access via
OpenID Connect, but beyond that the functionality is limited. The
OAuth 2.0 Client Credentials flow isn’t supported, and B2C doesn’t
include any API key management features, so you’ll need to roll your
own code if your services need to support API key authentication.
Another article with PROS for IdentityServer4.
IdentityServer 4 is an authentication framework capable of out of the
box Single Sign On (SSO) and security for your APIs, and most recently
support for implementing your own authentication protocols and tokens,
with a sample implementation for the WS-Federation protocol and SAML
tokens. SSO works across all applications regardless of whether they
are using OpenID Connect or WS-Federation.
Summary
IdentityServer4 is similar to Azure AD B2C with more functionality as noted in the linked articles.
Newbie question here on Authentication. I am used to incorporating authentication into my app backend server, like Spring Security Authentication for example. I don't really understand how the authentication providers work.
My concern is that somehow each provider can only authenticate its own accounts, ie google can only authenticate for gmail accounts, and Azure Active directory can only authenticate some kind of Microsoft registered account? I am disinclined to oauth because as a user I am always paranoid about signing in for some game or app from an unknown provider becacuse I never am sure whether I just gave my gmail or facebook account password to a rando.
I am fine giving people the option to use Oath, but less comfortable if that's the only option. I would like people to be able to give me whatever email address they want, and a password which they create for my site only.
Also these questions: If I use an authentication provider can I get the actual email address being used to log in? Or do I only get a token?
If I am going to build my own authentication service so I can accept any email domain as user name, what is the easiest to implement in Xamarin forms, and can somebody point me to a tutorial or something?
Advice appreciated thanks.
Yes, you're right, each identity provider provides the ability to authenticate their own users; Google OAuth supports Google accounts, Azure Active Directory supports Microsoft work & school accounts, Microsoft Account supports Microsoft personal accounts, and so on.
You have quite a few options on how to add support for these identity providers in your app, in addition to what we typically call 'local accounts', or accounts created specifically for the given application. I'll list out a few approaches:
You can write all the code yourself to integrate with each identity provider individually, and build-your-own local account solution as well.
You can use an SDK/library in your Xamarin Forms which facilitates using multiple identity providers within your app. The Xamarin.Auth package has historically served this purpose for Xamarin apps. It provides auth capabilities for Facebook, Google, Microsoft, and Twitter.
You can use a dedicated cloud service which provides authentication services for your app. Some examples include Azure Mobile Apps, Firebase Auth, Gigya, and more. The exact identity providers supported and the level of support for Xamarin/Xamarin Forms will vary across each one. Azure AD B2C is another option that I know supports Xamarin Forms as well as Facebook, Google, Twitter, and local accounts (disclaimer: I work on AAD B2C). These services sometimes have free tiers & paid tiers, so you can compare & contrast each.
You could also build your own authentication service using open source code like Identity Server if you wish.
It definitely depends which route you go, but generally speaking each solution will provide you access to some user profile information upon user authentication. For Azure AD B2C, you can configure the claims that are returned to your application in the tokens your app receives. For other services, you may need to make a REST API call to get some user data like the email address.
HTH.