I am new to OAuth2 concept.I ahve to implement this in my application. This application provides REST APIs. I follwed some tutorial ,done some research and kind of implemented it in working state in my application.
But while doing some search I read about different type of grant_type in OAuth2. I tried to learn about that but didn't get actual differences and which should I use for securing REST APIs.
So I want to know that for grant_type types "password","client_credential"etc which should be used and in which scenario, or which should be used for securing REST APIs?
Also at some places I found that the request for /oauth/token is different.
Some places the Authorization header is given as Basic 'some_encoded_string' .
And at some place it is Bearer 'some_encoded_string'. Whats the difference in these request?
Summarizing this I have 2 question -
For grant_type types "password","client_credential"etc which should be used and in which scenario, or which should be used for securing REST APIs?
What is the difference in ways of requesting token from /oauth/token .
Enlight my knowledge in implementing spring-security-oauth2.
The grant you need to use depends on your use case and the nature of the client application accessing your resources. There isn't a grant that applies a REST APIresource in general. You'd need to provide more information on what the APIs are and how you interact with them.
If a user has to give their permissions for a client to access an API, then you would normally use an "authorization code" grant. If the client accesses the resource directly without the intervention of an end user then it would normally use the "client credentials" grant.
You should avoid using the password grant in most cases, since it means the user has to provide their username and password to the client application. If the application can use another grant, such as authorization code, then that is preferable. A trusted application, such as a native application which the user installs on their computer, would be one situation where the password grant might be used.
A client would normally use "Basic" authentication to access the token endpoint. "Bearer" authentication is use to access a protected resource (such as your API), passing the access token it obtained from the authorization server.
Why do you think you need to use OAuth2 at all? I'm curious since you say you don't understand what the grant types are for. You really need to understand this before you can make a judgement about how you would use OAuth2 or why.
Related
I need to integrate OpenId connect for SPA application, without having token id in the URL, can we do that?
I'm assuming you have some security concerns with having the ID Token in the URL...
I can see two ways to mitigate risks in this case:
Make sure the OIDC provider redirects to your app using URL fragments instead of via the query string. This ensures that the parameters aren't sent to a server where they might end up in the logs, and should already be the provider's default response mode for implicit flows. If needed you can use response_mode=fragment to enforce it.
You could register a "public" client, but still use the authorization code flow to fetch the ID Token from the token endpoint. In this case you do not present a client_secret to the token endpoint (since the client is public). You could consider using PKCE in this flow as well.
I am developing a REST API using Java Spring Boot framework. Purpose of this API is to connect mobile and web applications so they can work together.
My question is, what are the best practices to develop login functions or the login process. Shall I generate a token or what should I do?
You could follow the best practices as described in OWASP, here.
Most APIs nowadays use token based security. Here are a few guidelines:
You need one service (which is itself public) that authenticates the user.
In order to authenticate the user, it might use a username and a password, and/or other means.
As the result of authenticating the user, this service returns an authorization token.
Your backend should keep track of issued tokens.
Each token will have an expiration time.
Every time the client uses an API, it should send along the token. Usually, the token is sent as an HTTP header.
Every service in the API should validate the token before anything else. If the token is invalid, it should return an appropiate HTTP code.
All communications should be sent over SSL.
OAuth and OAuth2 are two very well known protocols for this very goal. OAuth is a little more complicated than OAuth2.
This is a very high level description, not technically deep, but it should get you started.
I am searching for the best approach of authenticating users of mobile clients when accessing my RESTful API. For example, how approximately AirBnb uses it's auth module.
Should the authentication be different for RESTful and basic session-based resource, working with the same data?
I am not a mobile developer therefore, I am interested in what is the best way to provide authentication from server-side, so the mobile-platform developers could use it simply.
I googled for few approaches using OAuth, OAuth2, HTTPBasic authentication and still wonder how the mobile developers can use such API, how they will store this token (cookie is stored by browser in browser-oriented apps).
Could you please suggest me some links/code samples/techiques that you used in production or pet-projects or something?
An easy and manageable alternative to OAuth(2) for authentication is JWT.
You don't need additional infrastructure, the workflow and use is straightforward and there are ready to use libraries for all major languages already available.
Compared to HTTP Basic Authentication JWT is more flexible by transmitting additional information not just credentials, you can store the JWT token as JSON or you can use cookies, you don't need to store the credentials on client side and you don't transmit the credentials on every request.
Also based on JWT you can realize very easy a single sign on function. So if you need more than just a simple system user then you should definitely try JWT.
I have searched high and low for the answer to this question and now I'm reaching out to the community.
I'm trying to build an OAuth2 access token endpoint in Java.
I'll be implementing the resource owner credentials grant type to return an access token. (specifying end-user's username/password to get an access token)
During authentication of the user credentials, a number of rules could prevent the user from having access to my web service, such as the user account being locked.
The OAuth2 RFC says that errors must be returned as follows:
{ "error":"invalid_request", "error_description":"description", "error_uri":"some_link" }
It's also my understanding that the OAuth spec lists standard error codes and that you should avoid custom error codes in the response, like {"error":"account_locked"}; however, I've seen some API providers do this.
I need the clients of this API to be able to read an error code in the response to know when the account is locked. (or other specific scenarios)
Now my questions are:
Does anyone here have the experience to suggest how should this scenario be implemented?
Should I implement custom error codes?
Should I forget the OAuth2 spec and just build a /token endpoint that does the same thing: authenticates the user, generates the token, and returns my API's standard error response?
I don't have an exactly same senario. But I won't use custom error codes since it violates OAuth2. Instead, I may consider using the "error_description" as the error-code field in this case; Or I can add an biz_error_code field.
Yes, you can forget OAuth2, which is not flexible in terms of http status code and error_code. But you will end up building something very similar with OAuth2's 'password' grant_type, such as an access token and a refresh token.
I'm hosting a REST web service in a Grails application, using Spring Security, i.e.:
#Secured(['IS_AUTHENTICATED_REMEMBERED'])
def save = {
println "Save Ride REST WebMethod called"
}
I'm calling it from an Android app. (Calling the unsecured service works just fine.)
To call the service, I'm manually building up a request (HttpUriRequest) and executing it with an HttpClient.
I'm wondering what the best practices are, and how to implement them... Specifically, should I:
Perform a login once, to retrieve a JSESSION_ID, then add a header containing it into the HttpUriRequest for each subsequent request?
Or (not sure how I would even do this) include the login and password directly on each request, foregoing the cookie/server-side session
I think I can get option 1 working, but am not sure if Spring Security permits (2), if that's the way to go... Thanks!
--also, there isn't any library I'm missing that would do all this for me is there? :)
Spring security does support both basic authentication and form based authentication (embedding the username/password in the URL).
A REST service is generally authenticated on each and every request, not normally by a session. The default spring security authentication (assuming you're on 3.x) should look for basic authentication parameters or form parameters (j_username and j_password) (in the form http://you.com/rest_service?j_username=xyz&j_password=abc).
Manually tacking the j_username/j_password onto the URL, adding them as post parameters (I believe), or setting the basic authentication username/password should all work to authenticate a REST service against the default Spring Security interceptors, right out of the box.
I will admit that I haven't tried this on REST services, though I do clearly recall reading exactly this in the docs as I did the same for basic page logins on spring security recently. Disclaimer over.
I think you can use a login-once-and-get-a-token method that's similar to how oauth works.
sending username and password across the network outside of secured channel(https/ssl) is a terrible idea. anyone on the network can sniff your request package and see the clear text password.
on the other hand, if you use a token method, since the token string is randomly generated, even the token is compromised, the worst case is someone can use the token accessing your REST API.
another solution is going through ssl tunnel(HTTPS). i have actually done a comparison and result shows: 80 requests/min(https) vs 300 requests/min(http)