I have two ASP.NET websites, call them Older.com (using ancient ASP.NET WebPages) and Newer.com (which is a combination of WebPages and MVC), with separate login systems. I would like to allow the user of Older.com to be able to link their accounts to an existing Newer.com account, or create an account with Newer.com, and I think I want to do it using OAuth.
As I understand it, OAuth is generally used to allow users to login to a site using an existing account with the likes of Facebook, Google, Microsoft, etc.. However, I might not want to use Google/FB/MSoft accounts to create an OAuth token, but instead use an Older.com password to generate token that also grants them Newer.com access.
Basically, would it make sense to do this using OAuth? Do I have to use a link to an established provider Goog/FB/MSoft to use OAuth? And, are there security issues I should be concerned about when using OAuth?
Any advice, help, experience, or references are appreciated!
edit:
The reason for this is that resources that used to be hosted on Older.com are being moved to Newer.com, because Older.com needs to be rebuilt and the Newer.com is designed around storing and linking related resources. You could think of Newer.com as a place where you can keep an article, but you can also keep all the things related to that article (images, primary sources, derived works), whereas Older.com would just store a copy of the articles with no associated information.
wtyneb,
So there are a couple of ways to approach the problem you've encountered. There are many popular solutions to this problem, but two of them are: OAuth and OpenID. OAuth essentially allows access tokens to be issued to third-party clients by an authorization server. On the other hand, OpenID eliminates the need for webmasters to provide their own ad hoc systems and allowing users to consolidate their digital identities. In other words, users can log into multiple unrelated websites without having to register with their information over and over again.
The main difference between OAuth and OpenID is that OpenID is about authentication (ie. proving who you are), OAuth is about authorisation (ie. to grant access to functionality/data/etc.. without having to deal with the original authentication).
OAuth could be used in external partner sites to allow access to protected data without them having to re-authenticate a user.
In your case, if your users to Newer.com aren't using any information from Older.com, then it makes more of a sense to use an OpenID approach. Implementing OAuth would be over-engineering the solution in this case.
You can provide the credentials by either integrating OpenID into both your Older.com and Newer.com websites, or simply build out the same type of infrastructure into your back end. You can do that by simply exposing a REST API (which you might already be having to authenticate) in your Older.com website. What this does is simply verify the login credentials you have in Older.com when people log into your Newer.com, Newest.com, or any other website you might create in the future.
Please let me know if you have any questions!
Related
This is my first question on the Stackoverflow. I have already read the https://stackoverflow.com/help/how-to-ask section and I have read and read and read over the internet to find the connection between OAuth2 and MFA. Which made me more confused. When I take them separately I understand the basic concept.
Background. I am developing a windows application and using mailkit to implement the email there. When I research how to implement MFA on that, most of the answers are talking about OAuth2. That's why I really need to find an answer for this questions.
I have read
https://learn.microsoft.com/en-us/answers/questions/513048/microsoft-office-365-outlook-sending-emails-using.html and https://github.com/jstedfast/MailKit/blob/master/ExchangeOAuth2.md and many more articles to achieve my goal. They all are talking about OAuth2 not MFA.
I am sorry if my questions doesn't make much sense. Please help me to understand this.
Thank you.
OAuth 2.0 and MFA are not related to one another directly.
OAuth 2.0 is an authorization protocol which provides a client application with the delegated access. Way of delegation is defined by grant type and based on the use case you can choose one or another. It does not tell you directly how to authenticate the end user.
For example, using classic authorization code flow you can point the user to login page and optionally consent screen (allow / deny access to the app). An example of URL would be:
https://authorization-server.com/auth?response_type=code&client_id=CLIENT_ID&redirect_uri=REDIRECT_URI&scope=photos&state=1234zyx
Then it's up to authorization server how to authenticate the end user. It can be a login / password screen followed by any type of MFA.
MFA, on the other hand, stands for multi-factor authentication, meaning that there can be 2 of more factors of authentication (such as login and password pair followed by one time code, SMS or anything else).
Based on my understanding of the OAuth2 with Exchange that you've shared, you just need to register an application on Microsoft platform in order to access Microsoft APIs for email sending. That's indeed an OAuth 2.0, but I don't see anything related to MFA there.
https://identityserver4.readthedocs.io/en/release/intro/support.html
I currently issue tokens myself in my web api with JwtSecurityToken and I use standard ASP.NET Core middleware calling AddJwtBearer to verify the tokens. It works fine.
What advantage will give me using OpenID Connect (through IdentityServer4) over the approach described above? How to answer myself question "Do I need OpenID Connect?"
From my basic understanding about OpenID Connect, it is used to allow third parties to access your API. But I make API for myself and not for third parties and I don't know why should I favor IdentityServer/OpenIddict over my simple approach.
I read that if I want Single sign-on I should use this, but JWTs itself aren't bound to any specific domain and I can use single sign-on with just pure JWTs(they're self-contained)
I understand it implements some kind of standard for issuing tokens. (protocol). It might be good if I ever wish to expose some API to third parties. But for internal APIs? Is it worth using it?
This is my current auth flow (from https://jonhilton.net/2017/10/11/secure-your-asp.net-core-2.0-api-part-1---issuing-a-jwt/)
What I really want to implement to secure my Web API:
Login
Logout (invalidate token?)
No consent screen (want to have API only for myself), auth happens in the background in my native desktop, mobile, web app (no redirection)
Remember me feature (refresh tokens?)
Could someone clear out the fuzzy picture of OIDC/OAuth2 for me? i.e. give me some disadvantages going my own way (implementing my own flow) and advantages of using OIDC in place of my own flow.
What will it save me from doing later on (on the client-side for example), and what will not. And most particularly, is it good to start every project using standard flows like OIDC? Will it somehow benefit me in the future?
In any case you will implement OAuth2. Think of Oidc as an extension of OAuth2. The most important thing to keep in mind is seperation of concerns.
Forget Oidc, Identity Server 4 is all about authentication: "who is the user"? Consider Google login. When a user logs in for the first time, the application doesn't know the user, it only knows that Google does.
Authorization takes place on a different level and isn't really a concern of IdentityServer. For that you could take a look at PolicyServer.
So you'll need to keep the user database seperated from the application database. This doesn't mean you need another database, just don't mix contexts. If you have a relation from the "business context" to e.g. the user table in the "Identity context" then you are going to have a problem eventually.
In your setup your web api is both the resource and the identity provider. This means that every new web api you create has to be implemented as both resource and identity provider. For maintainability you could create a seperate web api that acts as an identity provider, while the web api is a resource only. You can implement something like that as long as all apps can read the token.
The same counts for the front. Why should the front have anything to do with the user? All it needs to do is pass the token in order to get the user authorized. In case of IdentityServer, the app contacts it to verify the user and receives a token. It knows nothing about credentials. This is more secure. The client app can be compromised. The credentials can be intercepted.
Having single apps with a specific concern makes things more maintainable. And it is quite easy to add a new resource without having to code when you use IdentityServer. Just add the configuration. It also allows you to add other flows in the future that are not needed at this time. And as a side note, the consent screen is optional.
The bonus is that you can implement SSO, where in your setup that could be harder, if not impossible.
So you don't have to use IdentityServer, nor Oidc. Your setup may be just fine. But if you build something, keep seperation of concerns in mind.
I am wondering if it is possible to use Microsoft's Graph API in order to create a cookie in IE given the username and password, (preferably using C# or VB.net), so that when the user connects to sharepoint with IE, he/she won't have to log into sharepoint via the login screens.
I'm having difficulty searching for examples because most examples describe how to authenticate a user. I am not looking to authenticate a user though, I am looking to create and store a cookie to force a user login.
Thank you for any advice.
No, and this should never be done. First because cookies are simply not secure. Secondly because you should never be storing any encrypted password anywhere.
I'm really not sure how Graph API fits into the scenario you provided. Microsoft Graph is a REST based API. It doesn't authenticated users on its own, you pass in a valid access token with each call. How you retrieve that token depends on if you're using delegated or application permission scopes.
From the scenario you described, it sounds like you're looking for SharePoint Single Sign-On (SSO). There are a few ways to do this but generally it is done using ADFS and AADSync. There is a walkthrough for setting this up: Step-By-Step: Setting up AD FS and Enabling Single Sign-On to Office 365. Be forewarned however, this is not a trivial process.
What are the best practice for implementing authentication for REST apis?
Using BASIC auth + SSL or something like https://datatracker.ietf.org/doc/html/draft-hammer-http-token-auth-01?
Are there any existing solutions available (for .NET / WebApi)?
The answer on this depends on the audience for your Web API and what you want to authenticate exactly.
Do you want to authenticate a client application that uses your Api?
Do you want to authenticate a user from your application to retrieve their data within a client application (using your Api)?
Or do you want to authenticate both the client application and the user using the client application.
Depending on what you want to authenticate you have multiple options. But always keep in mind that it is better to go with a solid solution where many client libraries are available than reinvent you own. Never do a little off this, but in your own way, chose one way of authentication, stick to it and don't break the client libraries.
Basic authentication: Is very easy to implement, but you authenticate a client app with it, not a user. This kind of authentication is nice when business trust relation needed and authentication and safety is not your very first concern. But there is no way to track a call in your API back to a certain user, just a client application. Of course you could save your user's username and password in a client application but this is a bad practice in more then a single way.
Token based authentication: Their are many ways of token authentication but the one i'm talking about here is a single token for a user which the user copies to the client application to get access to your Api. This way you can authenticate a user (who made this call in my Api?) And it is fairly easy to make and use. The withdrawal is that it is not the most secure way, requires user interaction and that a user possibly uses his Api token in more then one application. You could extend this way of authentication with basic authentication to authenticate a client. So a clientid + clientsecret + token to identify the user. But I think if you want to accomplish this it would be better to take a look at Oauth2.
OAuth2: If you want to have full access over your authentication you can go this way. It is possibly the most future proof way to go, but also requires the most work (at least at the identity provider/resource provider side. The client application has a fairly easy time implementing this with a lot available client libraries. If you go with this way of authentication (also token based) you can authenticate the client and the user, without the need to share your users username and password.
My recommendation: would be to go with Basic Authentication if this fits your case, it is easy and together with HTTPS is fairly safe. If it doesn't fit I would go with Oauth2 because it is the most solid and used standard (Instagram/Google/Facebook), gives you a lot off freedom and with a growing ecosystem gets easier and easier to implement. After all for someone implementing your API it is way more interesting to learn something about Oauth 2.0, then learn about the jgauffin way of doing things.
Reference: I would also like to invite you to have a look at Apigee's website. Api's are their business and they have quite some interesting reads. One of them is is a free ebook - Oauth the big picture which also has a interesting paragraph where they ask if you really need Oauth. (From page 16 - Is OAuth all you need for API security?)
For server-to-server APIs - APIs designed to be used only by a small number of servers –
OAuth is overkill. Having a separate set of authentication credentials for each app is a nice
feature of OAuth, but for server-to-server use, the need to log in securely using a browser,
or to implement other steps in the OAuth “dance,” gets in the way.
Instead, using a simple security standard like HTTP Basic authentication and assigning a
unique password to each app is sufficient. Two-way SSL is another good, albeit
cumbersome approach that has the advantage of stronger, more traceable authentication.
However, think ahead! Are those APIs really only going to be used by servers forever?
Exisisting Solutions: Whatever way you go leastprivilege - Dominick Baier and his nuget packages can give you a nice headstart. Implementing basic authentication using his Identitymodel is really easy. Also if you want a ready-to-go identityserver to provide you with tokens look at his identity server which does all you can think off. However if you decide to go for Oauth2 I would also have a look at DotnetOpenAuth since it is (imho) a bit more configurable and easier to tweak to your own like, but it also takes more work.
You should look into Security Token Service or STS.
Check out these links for more information:
Off-the-shelf Security Token Service (STS) that uses ASP.NET membership provider?
http://msdn.microsoft.com/en-us/library/ee517259.aspx
You could have a look here, IdentityModel has Web API support:
http://thinktecture.github.com/Thinktecture.IdentityModel.45/
We have an application which we need to allow users from our customer's systems to be able to sign in without seeing another log in screen.
What is the best way to provide an SSO type experience for our customers? I have tried to research Azure ACS and Windows Identity Framework but they all seem to be based on this idea of a common log in popup/screen which all sites use. Unless there is another aspect to this federated identity system I don't think that will work for us. Basically our customers are education institution which have students who sign in and use their own web applications/portals. These customers purchase access to our application and want their students to be able to click a link from their portal and automatically sign into our system.
From looking around it seems important to know that these systems are running on completely separate domains. For some legacy systems we have asked our customer to provide simple api endpoints for a very custom sso implementation. What I'm looking for is any information about a more standard approach for SSO.
SAML 2.0 is the standard for single-signon. Your clients would need to have some authentication mechanism on their sites that can be translated into a SAML call to your application.
When they sign the student on, they should make a quick call to your application, passing you the username of whoever is logged in. In return, you generate a token, store it in a DB along with the username, and send them the token. They append that token to any link to your app in GET form, and it "uses up" the token (removes it from the DB) but signs them in to that account.
Upon generating the token, you can also remove one "credit" from that applications allowed requests, or whatever else you want to do there.
Our specific needs required us to roll our own SSO type system using some simple secret token handshakes.