I am using OAuth 2 Authentication in Lumen microframework. Right now i am using the grant_type value is password. It throws unsupported_grant_type, If i am using something different. I want to know the purpose of using grant_type is password
The grant_type URL parameter is required by OAuth2 RFC for the /token endpoint, which exchanges a grant for real tokens. So the OAuth2 server knows what you are sending to it. You are using the Resource Owner Password Credentials Grant, so you must specify it with the value password.
From the OAuth2 RFC:
An authorization grant is a credential representing the resource
owner's authorization (to access its protected resources) used by the
client to obtain an access token.
The grant_type=password means that you are sending a username and a password to the /token endpoint. If you used the Authorization Code Grant flow, you could use the value authorization_code. But then you don't send the username+password pair, but a code received from the OAuth2 server after user authentication. The code is an arbitrary string - not human readable. It's nicely shown in the workflow diagrams in the RFC.
in OAuth 2.0, the term “grant type” refers to the way an application gets an access token. OAuth 2.0 defines several grant types, including the authorization code flow. OAuth 2.0 extensions can also define new grant types.
Related
How does authentication with JWT in Spring Boot work? Do I return my custom user and I set a filed called token to the JWT or do I return a JWT with all user information within in it to be extracted later? With the JWT for authorization I need my custom user information returned to be displayed in the app.
Here is few point JWT is designed to work:
Clients logs in by sending their credentials to the identity provider
The identity provider verifies the credentials; if all is OK, it retrieves the user data, generates a JWT containing user details and permissions that will be used to access the services, and it also sets the expiration on the JWT (which might be unlimited).
Client stores the JWT for a limited or unlimited amount of time, depending on the expiration set by the identity provider.
Client sends the stored JWT in an Authorization header for every request to the service provider.
For each request, the service provider takes the JWT from the Authorization header and decrypts it, if needed, validates the signature, and if everything is OK, extracts the user data and permissions. Based on this data solely, and again without looking up further details in the database or contacting the identity provider, it can accept or deny the client request. The only requirement is that the identity and service providers have an agreement on encryption so that service can verify the signature or even decrypt which identity was encrypted
A good hands-on example is here.
I have a Spring Boot Rest Api with JWT integration. Currently from Postman, I make a POST request to authenticate endpoint, including username and password, and obtain an access token.
But can Azure AD be used along with JWT, instead of hardcoded user details ?
When you obtain token with username and password, that bases on Resource Owner Password Credentials flow. This flow requires a very high degree of trust in the application, and carries risks which are not present in other flows.
I'm not sure what you mean about Azure AD with JWT.
If you would like to obtain access token with a signed-in user(not hardcoded user details), auth code flow is better for you. You could also request an access token in Postman.
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
client_id=xxx
&scope=https://graph.microsoft.com/mail.read
&code=<authorization_code from "/authorize" endpoint>
&redirect_uri=http%3A%2F%2Flocalhost%2Fmyapp%2F
&grant_type=authorization_code
If you would like to obtain access token without users, you could use client credentials flow. In the client credentials flow, permissions are granted directly to the application itself by an administrator, so you must use application permissions.
POST https://login.microsoftonline.com/{tenant}/oauth2/v2.0/token
client_id=xxx
&scope=https://graph.microsoft.com/.default
&client_secret=xxxx
&grant_type=client_credentials
I am developing some RESTful services for our mobile app using Spring Boot. I succesfully implemented Oauth2 authentication with our registration using username and password. Users can authenticate by using username and password. Also our client want to be authenticated with their custom token. They have a web service that you send token and response is true or false.
My first thought was, I can write a service like /custom-login and that service accepts custom token. In my service I can check this token with external service and if it is valid I call oauth2 authentication and return oauth2 authentication response.
How can I implement custom authentication oauth2 ?
OAuth2.0 spec allows for custom grant types,
So your auth server can create an custom grant type,
for eg: let's assume your wanted to authenticate with Google using Google access token, so you will create new grant_type called google_token
So now when your users wanted to authenticate using Google access token , they will pass like
grant_type=google_token&client_id=clientId&client_secret=secret&google_token=google-access-token
Then your auth server can verify the access token with Google and optionally verify client is issued to, etc and once verified , it can return your own access token
This applies for third party auth severs, so you can create number of custom grant types
I am using spring boot for backend and Android device for frontend of my system.
Right now I am facing the challenge to use Spring-OAuth2 to secure my resource server.
I have some questions, which I want to discuss with you:
My knowledge + this tutorial are saying that I should use the OAuth2.0 "password" grant type for my mobile app to obtain an access token. The official spring tutorial for security gives an example how to obtain the access token using password grant type:
$ curl client:secret#localhost:8080/oauth/token -d grant_type=password -d username=user -d password=pwd
And here comes my first question: Is there any possibility to obtain access token using the password grant type without sending the "client secret" ?
Since the client secret could be "reverse engineered" by decompiling the client app. The obtaining access token without secret should be somehow possible, because Facebook SDK for Android also does not need the client_secret in the mobile app.
I think here I have a little trouble understanding why the clientID + clientSecret needs to be included in the request above, because, since there are already username + password included, it should be possible to generate the access token, so does this brings a next level of security ? and does it implies the following (example): I am logged in as Filip in my Android client and I am sending the access token A with each request to the server. Then I log in as Filip into web client and I try to access the resource server from web client using the access token A, which is not possible because access token A was issued only for Android client ?
The next question is how can I refresh the obtained access token ?
I was trying to do so using the command below, but I got "Full authentication is required to access this resource." After I got the new refreshed token, can I use the refresh token to refresh my new access token again ?
curl -v --data "grant_type=refresh_token&client_id=acme&client_secret=acmesecret&refresh_token=REFRESH_TOKEN" http://localhost:9999/uaa/oauth/token
Thank you
The OAuth 2.0 spec allows for so-called public clients i.e. clients that don't authenticate themselves. So it is possible to use the Resource Owner Password Credentials grant with a public client, i.e. one that does not need to send a client secret. It does mean that the Authorization Server cannot assume anything about the client since a client_id is not a secret and there's no way to prevent a malicious client using this grant type or clients from impersonating each other. So using it in this way comes at the cost of reduced security although one may argue that in your case there's no way to use confidential clients anyhow, so there's no difference.
In general the Resource Owner Password Credentials grant is an anti-pattern for OAuth and only meant for migration purposes because it defeats most of the goals of OAuth in itself.
Access tokens are issued on a per-client basis.
You refresh token request seems OK but the Authorization Server may require basic authentication instead of providing the client_id/client_secret as post parameters, considering that you did the same for the original access token request.
I'm considering using authenticated encrypted JWT tokens to authenticate / authorized access to an ASP.NET Web API application.
Based on what I've read so far, it seems to me like it is an option to generate JWT tokens from a token service and pass them to Web API via the http authorization header.
I have found some good code examples on implementing the JWT creation and consumption (Pro ASP.NET Web API Security by Badrinarayanan Lakshmiraghavan).
I'm trying to understand if I need a full OAuth implementation to support this, or if I can simply pass the tokens along in the auth header.
Assuming the tokens are properly encrypted and signed, is there any inherent security flaw in keeping things simple without having to use OAuth?
Trying to keep things as simple as possible for my needs without compromising security.
It is not that you must always OAuth when you use tokens. But given the fact that your application is a JavaScript app, you would be better off implementing a 3-legged authentication. Thinktecture identity server does support implicit grant. But if the client application getting access to the user credential is not a problem for you, your JavaScript app can get the user ID and password from the user and make a token request from a token issuer ensuring the user ID and password are not stored any where in JavaScript app (including DOM). This request for token can be a simple HTTP POST as well and it does not need to be anything related to OAuth. If your end user will not enter the credentials in the client application, OAuth implicit grant is the way. BTW, you don't need to encrypt JWT. TIS issues signed JWT and that will ensure token integrity. But if you are worried about the confidentiality, you can use HTTPS to both obtain the token as well as present the token.
It looks like you don't really need auth delegation as the one provided by OAuth. Isn't HMAC authentication enough for your scenario ?. With HMAC, you will not have to deal with JWT at all. This is an implementation I made for HMAC authentication for .NET
https://github.com/pcibraro/hawknet
Pablo.