I'm fairly new to Oauth2 and it seems I'm stuck.
To protect our API, we use OAuth2. We have a lot of calls that contain information based on an account, se we use the password grant in OAuth.
But, I also have to protect my registration call, so only registered applications with valid client_id and client_secret can use that call. So, after reading a while, it seemed that I needed to use the client_credentials grant for those calls.
But now, I have absolutely no idea how I can define witch call should be using password of client_credentials.
Am I thinking wrong and is it impossible to use a specific grant for a specific call, or how can I define when to use what grant?
FYI: I'm using Laravel5.1 and Luca Degasperi's Laravel OAuth2 server
Thanks!
Usually you won't limit calls or routes to specific grant types and for several reasons it's nearly impossible to limit the client-application access via oauth grants.
So as a rule of thumb you should only expose the endpoints the user is allowed to access doesen't matter which client is used.
Further more I would prefer the client credentials or owner credentials grant, it's better in facts of usability and security (Change Password, Remove Access for specific apps, ...) more about the different grants.
Related
Im trying to find some best practices on how to solve my problem.
I have a microservice application with oauth2 and firebase for authentication and authorization.
Our application needs to connect to a 3rd party rest api which is secured with oauth2 as well.
Is it possible to integrate both implementations or do i need to make my own solution?
One of my co-workers implemented the authorization-code flow needed to access the api and we basicly store access and refresh_tokens in the database to access this 3rd party api. But it doesn't feel right, i cant find any best practices either, can anyone help me out?
What your co-worker implemented is pretty typical: separating out the authentication and authorization for your own application (which you manage with Firebase) from your users authorizing your use of the 3rd party API.
Here are some best practices you should be following when implementing your OAuth flow:
Use the state parameter to avoid CSRF attacks. Store it in your database and compare the callback state with the one that you randomly generated for the user
Encrypt access and refresh tokens. Refresh tokens in particular provide long-lived access
Verify that the scope you asked for is the scope that was returned: some providers allow users to adjust the permissions, which can lead to unexpected errors
Make sure your refresh tokens don't expire. Check with the provider's docs to see how refresh tokens are deauthorized. Some are time-based, some are based on new refresh tokens being issued, but in any case, make sure your refresh token stays valid, as if it is not, you must get the user to re-authorize your application
You can also use a managed OAuth provider to abstract away all these elements. Xkit, which I work on, integrates with Firebase Authentication so your users can authorize your app, and you can retrieve each user's tokens with one API call.
I'm sorry if this question is asked before, but I'm still confused.
I'm currently creating a REST API with laravel. I'm using passport to secure the API-endpoints. The API should be used/accessed from several websites and SPA's. BUT all this sites need to access the API on there own behalf. So there is no user that need to sign in! I found a lot of tutorials that cover the topic of authorization and authentication but only on behalf of a user.
So my question is: What oauth grant type shoud i use to secure my API considering that all api consumers act on there own behalf?
I tried to use the client credential grant because the documentation said that
The client credentials grant is suitable for machine-to-machine authentication.
But that creates a bearer token and it seems not save to store it in a SPA or generally on client side.
Has someone experience in this topic and can please provide an answer (maybe with a short explanation)?
A simple example of how I want to use some endpoints of the API to provide some context:
I created a location endpoint that receives a zip code and returns all the relevant places. I want to use this in a form. So that the user inputs his zip code and dynamically receives all the places in a select box, so that he can choose one and proceed with the form.
Thanks in advance!
Client sends username and password to the server.
Server then checks if this user is authenticated.
If yes, the server returns an access token for the client...
Then user can use this access token to access protected resources...
The advantage here, is that we are not sending user info via API calls, and the access token will not last for long time, so hackers won't be able to find out user authentication info (user name and password), and if he finds out, the access token won't last long enough to do anything with it.
That's how I understand Laravel passport API security.
The confusing thing here, is that on first API call, user has to send user name and password, so hacker still have big chance to find out user info!!!
I know that there is something wrong with my understanding, and that's why I get confused, any explanation would be very appreciated.
There must be a way to prove your identity to authorization server, and one way is to provide username and password. The way you're gonna achieve communication between authorization server and your client application is totally up to you as long as it uses HTTP. As stated in RFC-6749:
This specification is designed for use with HTTP ([RFC2616]). The
use of OAuth over any protocol other than HTTP is out of scope.
Of course it's always advised to use HTTPS whenever possible. Just because HTTP is mentioned in document, doesn't mean HTTPS cannot be used because HTTPS is just encrypted version of HTTP.
Other thing I wanted to mention is that you don't need to provide username and password, there are several grant types where you can, for example, instead of username and password you can provide client_id and client_secret which is used in Client Credentials grant type.
If you are new to this I believe this all is little bit confusing for you. To summarize the purpose of OAuth2 to you (as far as I get it), is:
To separate role of the client (which can be browser, mobile etc.) from the resource owner (usually the owner of account). Why? Because if there is no separation, the client has access to user's sensitive data.
Imagine that the first point is secure enough for communication. But what happens if someone gets their hands on the session you have? They have access to all! This is why OAuth introduces scopes, where depending on the scope user has with provided access token has limited access to resources. Scope can be read, write, share etc. - this implementation is up to developer. So if someone gets their hands on your access token, because of scope they only have a limited access to resource.
These are one of my reasons, while RFC-6749 has better explanation:
Third-party applications are required to store the resource
owner's credentials for future use, typically a password in
clear-text.
Servers are required to support password authentication, despite
the security weaknesses inherent in passwords.
Third-party applications gain overly broad access to the resource
owner's protected resources, leaving resource owners without any
ability to restrict duration or access to a limited subset of
resources.
Resource owners cannot revoke access to an individual third party
without revoking access to all third parties, and must do so by
changing the third party's password.
Compromise of any third-party application results in compromise of
the end-user's password and all of the data protected by that
password.
To learn more about OAuth2, it's grant types and purposes, I recommend you to read this:
An Introduction to OAuth 2
Mentioned RFC-6749, even though it can be difficult to read because of technical writing.
Hope I clarified at least a small piece of blur.
I am developing and API (laravel passport) services and a first-party app (VueJs) to consume api.
Api will have a 2 parts
Public - means user do NOT need to be logged in to see a content
Private - means user do NEED to be logged in to see a content
Token for Public areas:
Since the application is developed by trusted source (same developers for api) I should be using a Client Credentials grant-type. However, since this is also a web-app, client credentials' confidentiality is not guaranteed.
So then I would need to use an Implicit grant type where a client_secret is not required. Then a user will have to authorize, which doesn't make much sense for a first-party app.
Token for Private areas:
It is obvious that I just need to use a Resource Owner Password Credentials grant type. Confusion come, as the client credentials will still be passed together with user credentials. And the client credentials can be used in public areas.
I am so very confused as which of the grant type(s) should be used in this case? Or is it fine to just use different grant types together?
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.