I've been reading a lot lately about WEB API authentication mechanisms and I'm a little bit confused regarding how to implement my Web API authentication mechanism, I'm thinking on using Token based authentication but I'm not sure if it is the right choice.
Basically my Web API will manage all the operations needed and it will store the users of my website as well the API users(in case they have to be separated).
I want to support the following
User can register on my website and apps using their G+ or Facebook account or an already created username from my service, as well they will be to login using their social account.
If the user is not logged in they won't be able to post Items but they will be able to see the Items, think something like Craiglist.
Let's say the user is a developer and they want to post the items through some software they created instead of going through the website and posting one item at a time, how do I allow this?
Now, my questions are: 1) When a user registers on my website, do I have to create a (public key/ secret key) for it subsequent access token , so I can use my API from the website as the user checking if they have access to certain endpoints?
2) Do I have to assign a (public key / secret key) for my website so I can consume the API when the user is not logged in?
3) The same as above for mobile apps
4) How do I allow users to (sign up / sign in) using G+ or Facebook?, if they log in using any social network how am I going to secure my api?
Please, any answer will be really appreciated.
Thanks
For ASP.NET Web API 2, I would recommend you to use the default Owin OAuth2 authentication. It's a standard form of authentication well documented enough. If you do not have enough knowledge about OAuth2, read the RFC.
With Web API 2, ASP.NET moved to a new security model, called ASP.NET Identity. There is this really good video that explains the basics. The point is that starts from scratch, ignoring traditional basic, forms, or windows authentication.
A lot of learning material is on the ASP.NET website.
For local, individual accounts (questions #1, #2, and #3), look through this tutorial - here basically your own server will act as an OAuth authorization server, and the Owin OAuth2 implementation will take care of generating access token and authenticating them. Since you'll be using the OAuth 2 standard, it will be basically the same for mobile as well.
For external accounts (question #4), read through this tutorial. There are official libraries for third-party authentication for the major providers:
Microsoft.Owin.Security.Facebook
Microsoft.Owin.Security.Google
Microsoft.Owin.Security.Twitter
Microsoft.Owin.Security.MicrosoftAccount
It would helpful to also learn more and understand the new OWIN specification, that describes how web apps need to created for the .NET framework, and the Katana project (Microsoft's OWIN implementation).
Follow this tutorial for most of your requirements http://bitoftech.net/2015/01/21/asp-net-identity-2-with-asp-net-web-api-2-accounts-management/ Logging in via facebook/G+ MVC already has the helpers commented out. You would get the credentials by setting up key's via the third party apps and then store the identity.
Related
I have a working implementation of IdentityServer4 with custom user stores, etc.
I have an asp.net core web app that I want to require user login for certain pages through the IdentityServer4 instance with my site having full ASP.Net Core Identity functionality e.g. my razor pages accessing User etc.
I have been searching for 3 days and while the internet seems to have lots of resources available on very similar topics, they all do things a little differently. I feel like I just don't know the right keywords to search for.
I have been following many online tutorials such as JWT Authentication on .Net Core and all of the quickstarts on identityserver4.io but they all leave out crucial steps.
IdentityServer is an implementation of oidc, which means that it serves as an independent, central authentication point. Client apps should be unaware of users credentials. That's part of the responsibility of IdentityServer.
So the reason you won't find answers and you think steps are missing, is because you are not implementing oidc.
It is not possible to 'hide' IdentityServer when a user has to login there.
That leaves you with three options:
implement Resource owner password flow. In that case you can collect the credentials and send it to IdentityServer. Please note that there may be security issues when you use this.
Do not use IdentityServer but instead implement Asp.Net Core Identity.
Send information to IdentityServer to identify the client and use custom presentation for that client. In that case the url may be different but the look and feel remains the same.
I have been doing a lot of research into how to authenticate mobile apps with an API - I still feel a bit unsure about which flow & architecture would be better to use in my particular use case.
I think what's confusing me is some of the terminology used.
My use case:
An API & database on one server. Which holds the users & and the users resources.
A web app, which I have built and consumes the API. Hosted on the same server as the API. So it's dogfooding.
A web app, which I have built and consumes the API. Hosted on a different server to the API.
A mobile app, which I have built and consumes the API.
I'd like to be able to authenticate with the API using username & password.
The API will never be opened up for consumption by other 3rd party services except the web app and the mobile app.
Initially I felt like using the Resource Owner Password Credentials Grant flow would be sufficient. However in the docs it states that this flow should be used if "The client is absolutely trusted with the user credentials".
Since both my mobile & web apps will be built by me, I'm assuming they are seen as 1st party clients. Therefore am I right in thinking they are considered to be trusted with the user credentials? As I typically thought that when implementing oAuth, the idea would be to have the authentication server separate from the resource server. Which would allow you to have one authentication server for multiple APIs.
After reading this post: Why the Password Grant is not suitable for modern applications
It threw me off track a bit. But then, is this post talking about using this flow in my use case?
I was also looking at the Implicit Grant Tokens flow. However using this flow I couldn't really see how the user would enter their credentials first?
I also question if any of the oAuth flows is really needed for my use case and I should instead look at other ways of authenticating?
I'm really quite lost with this I would like some direction to go in with how to authenticate users in my particular case.
Thanks in advance!
I'll most likely be using Laravel to house my API and so I do have Passport available to me to implement oAuth
EDIT
From following this oauth article I've found that in all use cases of my app, I end at Password Credentials Grant flow. Would I be correct here?
I have Angular 2 application which talks to the Web API and does some basic CRUD operations. I have few questions:
Is any way I can create a Login/Register page on Angular 2 using ASP.NET Identity?
How do I manipulate with a data only relates to the logged in user? (Token Based Authentication? How it works? Where to read about it?)
How can I implement login/register process on actual Angular 2 application without redirecting me to Identity Server?
I looked at IdentityServer4, OAuth2 and OpenID examples, it is a bit too complex to understand. I went thru every single step in quick start, it works but I don't understand how and what it does.
Can someone give me any resources where I can start from? Blogs, websites, books, step-by-step guides.
You're correct that at this point the most comprehensive solutions for authentication and authorization in systems that rely heavily on HTTP are based on OAuth 2.0 and OpenID Connect. This of course includes your specific scenario of a SPA calling a Web API back-end. For further read on this generic case you can check the Auth0 SPA + API Architecture Scenario or give a look at the quickstarts focused on your selected technologies:
Angular2 Quickstart
ASP.NET Core Web API Quickstart
Note: Auth0 supports OAuth 2.0/OpenID Connect so even though the docs may have additional features that are provider-specific, you may find them useful if you do indeed decide to go the OAuth 2.0/OpenID Connect route. It's one of the advantage points of relying on standards, it's easier to switch between implementation/providers.
However, you should also consider if you really need to go full OAuth 2.0/OpenID Connect as they aim to solve a lot of different use cases and as such also bring significant complexity with them. If you go that route, it's recommended that you leverage existing libraries like IdentityServer or cloud providers like Auth0, because doing your own implementation carries a lot of risk and requires significant effort.
In order to meet your requirement of providing an integrated login from within your own Angular2 front-end you could probably look into the resource owner password credentials grant specified by OAuth2.
Another alternative is doing your own custom solution, this is generally frowned upon, because it's easy to get wrong, but the theory would be:
Handle user authentication and registration (possibly using ASP .NET Identity)
Upon login exchange user credentials with some a token that you can later use to call into the API
The token could just be a random (not guessable) value used as a reference to some server-side storage that would contain information about the associated user.
I'm developing an ASP.Net MVC 4 Web API application where this application will be the source data for different Mobile/Web client apps. I need to authenticate a user so I can return the correct set of content for the user. I'm thinking about using an API Key that is sent to every request of my Web API application. The API Key identifies the user. I found this post that outlines a potential solution: From API Key to User with ASP.NET Web API
I need to support forms authentication as well as oAuth 2.0 for Facebook, Twitter, etc. All of these approaches yield a token I can use to send back and forth from the different clients to my Web API so I can identify the user. I understand Facebook access tokens expire. I'm a little confused on what's the best way to deal with Facebook interactions. Which of the following paths is the best way to go:
Rely on the different client apps to authenticate against Facebook (and other oAuth providers) to establish a Facebook access token that's then forwarded to my Web API application? This means all of the clients are responsible for making sure the Facebook access token is not expired. The Web API app assumes the access token is always valid. This seems dangerous to me. The different apps would authenticate the user then send user information to WebAPI app to register the user in order for the user to consume the data from my Web API app. This seems like a lot of duplication.
Make my Web API application solely responsible for interacting with Facebook (and other oAuth providers) on behalf of all the different client apps using my Web API. So this approach seems to suggest I need to build some sort of authenticating UI for my Web API app. I know ASP.Net MVC Web API can have views and front end stuff, but it always seems to me that you are mixing things together. It seems Web API apps should be singularly focused on returning data. Users from all of the different client apps will register with my Web Api app by either filling out a registration form, or using Facebook, Twitter, etc. Is it OK to mix UI views in with a pure REST Web API application? Then you have to start worrying about everything that goes with UIs on different devices, etc.
Is there another way I'm not seeing?
I really appreciate any guidance and links to examples you might have. Thanks for your time.
I would suggest you below approach:
1. Create an authentication API which will authenticate the user. If user is authenticated successfully, create a session (self implemented, may be a record in your db) for that user.
2. Next time user call your other APIs which returns content for that user. In this case it would be must for that user to provider the session id (which you have created in first step) to get the content. If sessionId provided by user does not exist at your end, it means the user is not authenticated. In this case you can return authentication error message to the user telling that he needs to get authenticated first. It is very flexible, scaleable solution in a way that you can store many information regarding that user session. Also once authenticated, user does not need to get authenticated every time he calls your other APIs to get content. It would save you as well from authenticating the user every time.
I'm writing a Windows 8 Metro app (client-server) and would like to allow my users to login using their existing accounts (Windows Live, Google, Facebook, Yahoo, ...).
Currently I'm using OAuth 2.0 on the client to retrieve a code which can be used on the server side to fetch an access token from the provider and to read basic information about the account.
I recently read about OpenID, but it seems, that there are no implementations for desktop applications. Also, Windows Live doesn't seem to support OpenID.
So my questions are:
Is it a bad practice to use OAuth to delegate authentication only?
Should I implement my own OAuth provider in ASP.NET for API access of my client and delegate the authentication task to OpenID-Providers in the OAuth web forms?
OAuth is overkill if you're only wanting to authenticate a user (after all, you're asking your customer if you can act on their behalf with the service used to authenticate with); Or, as a more concrete example, if you were delegating authentication to Twitter, you could also read all their contacts and lots of other stuff that you don't need - that might be enough to put some customers off using your app, and giving it a bad review in the store.
It's slightly different when the customer already has a relationship with the web service, and understands that your application is a client of it.