I'm having trouble wrapping my head around implementing the client-credentials flow on the client side. Say the client requests a secure endpoint in an API without being authorized. The API will respond with 401 and that's that? As i understand it the client-credential flow should not require any user interaction, am i correct? Specifically, the client should not need to click, say, a button "Authorize client" before visiting any page that accesses protected resources?
You're right that there is no user interaction necessary. However, you must call the /token endpoint (with your credentials) to get back a token that you will later use in your API request's Authorization header.
Related
In our case we need password credentials grant type, but since it is removed from both OAuth 2.1 specification and spring-authorization-server implementation I want to use the default AuthorizationGrantType.AUTHORIZATION_CODE authorization grant type but with some tweaks due to out case.
Instead Login form I want to use Basic auth since token will be requested by gateway service and we also will be secured outside and actually instead username+password we will use just username. So I need to avoid Login page since user will not see it and I have only machine-to-machine request.
The problem is that simply changing .formLogin() to .httpBasic() doesn't work. If I follow default pipeline with url in a browser then basic login form popup and after submitting credentials it shows up again and nothing happens. In the postman if I send same get request to /oauth2/authorize I just got 401 status code. If I authenticate with some another endpoint and then try to call get on /oauth2/authorize again I will get 400 instead of 401 but that's all.
So could someone help me with using httpBasic or suggest other ways to get token without getting Login page just with REST requests.
httpBasic is not OAuth2. Password flow is weak, reason for it to be abandonned. It is also a poor user experience compared to SSO solutions that serious authorization-server offer now a days.
If you want to authenticate a robot in its own name (not on behalf of an authenticated user), use client credentials flow, it does just that: authenticate (as itself) a program you can trust to keep a secret actually secret (running on your infrastructure and not in a browser somewhere on the internet)
If it is users that you want to authenticate, just have your clients use authorization-code flow (for Angular, with angular-auth-oidc-client, or an equivalent for your client(s) framework(s))
I`m new to OAuth 2.0 and am trying to develop a application using a third party OAuth provider with Authorization Code grant flow as ny Authorization Server and Spring Security.
This provider gives me two endpoints /authorize and /token and those two, after the user authorizes its access, will return a access token.
So far, I have secured the "/" endpoint, so the application redirect the user to the authorization page and then, in the callback endpoint, store the token so it can be validated by a filter in each request.
But, as the application is mainly a set of REST API's, we want to be able to test it using Postman, with that said, on Postman, I am getting the token by setting the Authorization as OAuth 2.0 and requesting the token directly from the third party endpoints but, as Postman have its own callback URI, my application doesn`t store the token generated.
So, my two questions on this are:
Using /callback endpoint to store the token and validating it before each request by a filter is the common way of doing it?
To use Postman, should I create an endpoint for storing the token generated outside the application context or should I create an Authorization Server of my own as an additional layer on top of this third party AS?
Since your application is a set of REST API's, you need to make it as a Resource Server (in terms of OAuth2).
Resource Server doesn't perform authentication itself, it only validates a token from Authorization header (Resource Server in a nutshell).
You can find an example in Spring Security samples: oauth2resourceserver
I eventually come to the conclusion that I was using Postman wrong the whole time.
So, by the end, we got the Token saved on the database when the user logs in and, then, return it to the caller, whether it is the Front-end application, or Postman itself.
Then, in every call to the API's, the caller should include the token as Authorization on the header and a Filter on Spring will check the token against the Database.
On all OAuth2 documentations i looked, including the Oauth2 spec, the Oauth2 Authorization Code flow ends in the point where the server side holds both the refresh and access tokens.
As a server-side of a web app, what I wish is to not finish the flow here, but response my web user agent with the access\refresh tokens
This in order to have my user agent later make calls to my app's server-side APIs using the access token for auth (the app's server-side will verify the token against the authorization server).
The implicit flow might be the flow i should have been using here (right?), but the authorization server in my company supports only the authorization code flow (and not the implicit flow) for now.
I thought of adding a redirect url as a query param inside of the redirect url of the authorization API.
This way, when the authorization flow will ends, and my app's server side will get the tokens, it will redirect back to the User agent's url, providing the access\refresh tokens as hash fragments
Is it safe for the server-side to redirect to user agent with the tokens this way?
Is there any better practice for redirect back to the user agent?
I am writing a REST API to be consumed by our internal applications. I need to login and logout users of the identity server using code grant via http requests
presentation
I need to know how to call the following endpoints:
/authorize (invoked from server-side)
/accesstoken (invoked from server-side)
/login
/logout
CASE:
Our company has many applications. I want one point of authentication which will happen in their company-x account like how you only need to login to atlassian account to access jira and confluence cloud. The REST API I'm working is for our front-end developers (as of now).
presentation
I cannot simply let the user login to WSO2 IS since they only need a module where they can manage their company-x profile and other basic stuffs. By this I think I have 2 options:
Customize WSO2 Identity Server UI and permissions. But the problem is, I still need an endpoint to get that id_token. I am also not sure if this is the right approach.
Know how to call /authorize, /accesstoken, /login and /logout endpoint and write my own minimal required UI and provide an endpoint that will respond the id_token
How about having a basic login page on front-end and use request path authenticator to get the authorization code/id_token.
Basically what this means is instead of redirecting the user to IS login page you can extract the username and password from the basic login page you created and send the authorization grant request along with the credentials.
so your authorization code request will be:
https://localhost:9443/oauth2/authorize?response_type=code&client_id=JqB4NGZLMC6L3n4jz094FMls2Joa&redirect_uri=https://localhost/callback&scope=openid§oken=<sec_token>
sec_token = base64encode(username:password)
You need to add basic-auth request path authenticator in your Service Provider configurations. This request should return you an authorization code. If you want an id_token simply use the implicit flow with request path authentication.
If you use code grant type, there will be a browser redirection from /authorize to /login. I don't think you can handle that by a REST call. (You might be able to handle that by calling url in location header of each 302 response. But I don't think it's a nice way to do this.) If you want to develop a REST API, I think password grant type will be more suitable.
In the Google developer console, when you create new app credentials for use in OAuth 2.0, and you specify a web app, it requests that you register callback URI and JavaScript origins.
I don't have a precise understanding of the need to register these.
For the callback URI, presumably this prevents a 3rd party who presents a malicious page to a user from getting the authorization code. However, the client id and secret are still hidden in the app server, so isn't the malicious application unable to do anything anyway?
Furthermore, if the callback URI is already registered, what does registering the JS origins separately accomplish. Unlike the callback URI registration, this is not mentioned by the OAuth 2.0 spec, it's something Google chose to implement.
Thank you for your help!
When you request a token, that token will be passed to the callback URL. By only permitting callback URLs that you have configured in the API console, you are preventing malicious users from spoofing the request and having the token sent to a third party. I suspect the aspect of OAuth that you've missed is that the callback is sent via a browser redirect, so is easy to fake.
Callback URLs are part of the OAuth server flow.
JS Origins come into play when you are using the client (Javascript) OAuth flow. They ensure that any OAuth request has come from a page that originated on your site.
The server flow is ...
OK I think I understand a bit more from reading the spec. https://www.rfc-editor.org/rfc/rfc6749#section-10.6
It is to prevent an attack by a user of the same client An attacker can create an account at the same client and initiate auth flow, but he replaces the redirect URI with his own URI.
He then tricks a victim into following the link to authorize the same legit client they are using. However, the auth code is now sent to the attacker URI.
The attacker then completes the flow by providing the auth code back to the client, which the client uses to complete the flow obtaining the token. However, this token may be associated by the client with the attacker, allowing him to impersonate the victim.