Restructuring existing Web API - should I use OAuth? - asp.net-web-api

Most articles on MVC WebAPI OAuth assume there is some resource owner (like a person) who will authorize the release of data. In our case the data is public, like product for sale, or name of departments etc. The API just hides unnecessary/malicious access to things like date created, activity user etc. - and of course saves the front end developer from learning database schema.
Does OAuth fit in this scenario where no particular owner exists?

Does OAuth fit in this scenario where no particular owner exists?
Yes it does.
Sure, the primary focus of the OAuth specification is to protect resoures owned by the resource owner, but it can of course protect other resources too. Take Facebook for example: it protects not only your data, but also the data of your friends, which is accessible by you.
In your case, you need to protect those fields, and OAuth is a good mechanism for users with the necessary rights to authorize an application to access those fields. Users without the necessary rights (if those are registered users at all) would of course not be able to do so.
In addition, there usually is one resource that is owned by the user: the user's profile data.
OAuth 2.0 is the best protocol available today to secure a web API.

If you allow anyone (= any client application) to access your APIs without any restriction, you don't have to care about OAuth.
On the other hand, if you want to allow accesses only from client applications that have been registered in advance, "Client Credentials Flow" in RFC 6749 (OAuth 2.0) is probably the best for you. The flow does not associate an access token with any specific resource owner. An access token is issued based on only the client credentials (= client ID and client secret) of a client application.

Related

express-gateway API key management

I have API backend and it will be consumed by different consumers like our own company website and even other website can use our API with certain quota/limitation and for this scope management we will be using express-gateway(eg), however this is not the only reason I am using express-gateway(eg). Now coming to my problem/miss-understanding, for our own website we can create api-key and user credentials using eg command. But for the other user who wishes to use our api, I don’t want them to contact me for this integration, rather they should be able to create a user credentials and API key themselves using some facility (let us call it key management) provided by us. Here I am stuck how to give a web platform or any other mechanism where a user can create account and then create api-key for their own website. I was thinking to extend the express-gateway app itself and create page where a website owner can fill the form with various input field that will serve as parameter for eg command and I can trigger eg command in node console and create credentials and save it in redis database and then fetch those information to show it to user as their use rid and api-key. But I want to know the best way how others are doing, like how google, twitter and many more are allowing to create api-key, delete key and regenerate the api-key on compromise. Some suggestion would be to use third party tool to manage user-credentials, I will have little inertia to accept that, even if I do so how will I hook those third-party solution to my express-gateway.
In general, API gateways and authentication servers are independent, or at least loosely-coupled. The typical workflow is:
A user browses to the Create Account page for a service.
The user creates an account with the authentication server
The user makes a request through the API gateway
The API gateway checks with the authentication server whether the operation is allowed, discarding it if the user is not authorized to perform the requested action
The API gateway dispatches the request to the appropriate server
The receiving server checks whether the user is permitted to perform the action (in case the API gateway has been compromised)
Express Gateway includes its own authentication server for convenience, but the steps are basically the same. The difference is that one uses the Express Gateway Admin API to create the user and credentials rather than going to a different server.
Note that Express Gateway and its default account database (reddis) are not persistent out of the box.

Where is the best place to keep authorization server in microservices?

I am designing a set of microservices for user management, api gateway, cart & checkout, promotions etc (ecommerce services). Planning to manage authentication and authorization using jwt token. Which service would be the best place to keep the authorization server?
I have refered a few designs where its found on the api gateway, but I need a separate user management service and users table is maintained here (other services like cart checkout etc would be resource servers) Grant types: client_credentials and password are required.
Are there any existing open source projects I can refer? Any documentation available for best practives?
If you are maintaining user data alongwith with the Authorization server, I woud suggest you to register this as a separate micro-service as AuthService in your RegistryService.
Best practice should be to use a JDBCTokenStore so that user is authenticated even if service instance get stopped or disrupted.
You shall include a dedicated DB for this service that shall include tables for User details, grant authorities, access tokens and refresh tokens.

Can Oauth2 replace session (or other similar means) to keep user login information at server side?

I'm a little new to this and please bear with me if I ask dumb questions.
As what I know, session is something saved at server (either in file or in database), and client access it via sessionid saved in cookie. To keep user login information, we can simply put a 'logged_in' column and an 'expired' column in session file or session table.
As far as I know, Oauth2.0 is designed for third party client to access the server. The whole process is controlled by an access_token, which is quite similar to sessionid (at least from my knowledge).
So, here's my question, is it possible to use Oauth2.0 to completely replace session? I.e., even people are using the website designed by me (NOT third party website) to access my own server? So that I have a unified authorization framework for user accesses both from my own website and any thrid party website.
Is there any pros&cons of using session & oauth 2.0?
Lastly, how about mobile app? I know for third party mobile app, they normally use oauth to access the server (many websites provides oauth api). How about if I am going to write my own app for my own server (NOT third party)? Does Oauth 2.0 apply here too?
To summarize, my question is actually is, is Oauth 2.0 universal that can be used in all kinds of user authorization control situations from all kinds of devices?
Thank you very much.
Though both are short-living entities, session IDs and OAuth tokens are fundamentally different and used for distinct scenarios. A session is used to identify a user of a web application, thus related to the end user. An OAuth token is used to grant access to a third-party service to access a limited set of protected user resources (e.g. read user contact information or send a mail from the user account). Though the token refers to the granter (i.e. end user authorized the grant), the token related more to the third-party application.
To give you an analogous example: imagine that you have a safe at your bank (i.e. your protected resource). The session is your id for the bank: give it to someone else and he will be you, he can get everything from your safe. On the other hand, a token is a limited authorization to someone else to your safe: e.g. your approval that he can get 10$ from your safe while a security guard is watching.
As a summary, sessions and tokens are not interchangable.

Login with facebook and using oauth 2.0 for authentication of REST api calls

I am using spring framework and REST architecutre in my api. Currently I am authenticating my REST call by sending username and password with every call. And users are stored in my database.
Now I plan to use oauth 2.0 for access to my protected resources and also i plan to use Facebook Login as authentication mechanism.
I have read about spring-security-oauth2 and have implemented in a small example it works fine.
I have read about spring-social and also have implemented it and can access facebook api.
Now all I want to know is how can i login with facebook and then use oauth 2.0 to protect my
resources.
Any help will be deeply appreciated.
You would not want to use the Facebook-issued access token to secure your own resources. The Facebook token represents a 3-way agreement between your application, Facebook, and your user. If you want to use OAuth to secure your own resources, that's a completely different agreement between the consumer of those resources, your server, and the user who owns those resources on your server.
Think of it this way: When you are consuming Facebook's API, your application (A) is the consumer, Facebook (FB) is the provider, and there's a common user (U1) that joins those together. But when someone is consuming resources on your server, then your application (A) is in the role of the provider, some other application (X) is the consumer, and there's a common user (U2) who joins those together. It may be the same human (e.g., U1 == U2) that agreed to the arrangement in both cases, but the roles of provider and consumer have changed.
I imagine that there's probably a way to get Spring Security for OAuth to issue the same access token that Facebook issued, but that's not really a good idea.

Supporting both existing forms authentication login and Federated WebSSO

We are having a hosted web application and it uses forms authentication.
This webapplication is accessed by users belong to different partner organizations.
Currently users belong to the partner organizations are accessing the application using the credentials that we give it to them.
Now, some partner organizations wants their users to access the application using their active directory credentials.
We are planning to use ADFS for these partner organizations, so the users will be authenticated using Active Directory within their network and claims will be sent to the webapp via the Authentication token cookie set by the ADFS. From the claims, we map the users to the internal userIds of the web application.
My questions are , if we make the web application ADFS enabled,
1)Is it possible to still allow the other partner organization users(who don't want to use ADFS) to login to the web application using the existing login page(forms authentication)?
2) Should every page in the ADFS enabled webapp be accessed through https?
Any solutions or pointers would be much appreciated.
Thanks
-arul
Your app needs to require claims that describe the user, regardless of where they login from. It should not handle authentication in either case; this should be delegated to a trusted issuer, an STS. This will allow it to interact w/ users in a uniform way irrespective of where and how they authenticate. This means that you're going to need to use ADFS in two roles: that of an Identity Provider (IP) STS and of a Federation Provider (FP) STS. For users of partner companies that don't want to maintain users themselves, you'll be the IP-STS; for those that do, you'll be an FP-STS. In the latter case, ADFS will redirect users from your realm back to the partner's site where their IP-STS will authenticate them and send them to your FP-STS. It will map your partner's user ID and claims into ones that make sense in your realm. This and other information about the user will be included in the set of claims that are issued from your FP-STS. As a result, your app, only trusts your STS regardless of which scenario is appropriate for different users. Note that in this scenerio, there will be two STSs: your ADFS FP-STS and your partner's IP-STS, which may or may not be ADFS. In the other case, there will only be one STS: your IP-STS.
Not every page on your ADFS Web app needs to be accessed via HTTPS; however, everyone that's used in the authentication process should be.
This is really a non-trivial undertaking. If you want to talk about it more, please feel free to get in touch w/ me.

Resources