I am using NiFi invokeHttp processor to send the data to some other third party server.
The third party server is oauth2 protected, so I need to login and get the JWT token after getting it, invoke http needs to add it in header 'Authorization:"JWTtoken"' before sending to third-party server and refresh it when it expires.
When I went through NiFi invokehttp processor it does not have any option for oauth2 flow options.
During search I got few links oauth-template, this is very big flow to get a token which is adding more nifi processor stuffs ,
And this link shows there is some Jira ticket on the same but I could not find same in recent NiFi. Hence is there a better flow to handle oauth2 when sending the data to other third party server.
Related
I entered my credentials and logged into a web application protected by OAuth Authorization Code flow. Then I performed below steps:
Open browser developer tools (F12) and start capturing network traffic
Try to get data from an API. This request will require access token to be sent. But I am able to view the access token on the network tab for that particular request in the request headers as seen in screenshot below:
My understanding was as below:
The access token would be stored on the web server where my web application is running. That will never be stored in the browser.
Since I am able to see it in the network tab, where exactly is the access token stored in the browser? We use Azure AD as the IDP and Owin packages to integrate OAuth auth code flow.
The API request is over HTTPS and I am able to view the full request details in network tab. Is this expected?
There are only so many places where you can persistently store data in the browser.
As of this writing:
Cookies
Session Storage
Local Storage
IndexedDB
Web SQL
If you are using libraries to implement the OAuth2 flow any of these could be used. You can find and inspect these storage systems under the "application" developer tools tab in Chrome, or similar spots in other browsers. What you can see/inspect depends on the domain you are currently on in the active tab.
If your client is server based, and thus confidential, you should store your token in a Secure HttpOnly cookie. Then proxy requests to the backend through your own server, including the bearer token from the cookie. This would be the best spot.
If your client is a single page application, you should consider storing it "in memory" and just reauthorize when reloading the page.
If that is not an option then Session Storage is your most secure option. This is most often used if OAuth2 is performed by your frontend.
In any case, if the OAuth2 flow is performed by frontend components only, it is to be expected that the token resides somewhere in the mentioned storage systems, and that it is included in the requests as visible in the network tab of your developer tools.
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.
I am looking for fittings ends to our SSO puzzle.
Currently we have an OpenLDAP behind WSO2 Identity Provider. A client (Service Provider) redirects authorization to the IP (OAuth2) and recieves an access_token.
All fine.
Next step is to validate this token on another Service Provider, in this case a reverse proxy (Apache or Nginx) residing on another EC2 instance, which protects a number of unprotected 3rd party applications (3rd party in the sense that we can't touch source code, but do the hosting our selves). Which tools do serve this request?
Am am aware that the OAuth2 spec leaves a hiatus here and that there is draft which adds a /introspect call to validate this token. I also know that pingidentity implements this draft as part of there Apache module (https://github.com/pingidentity/mod_auth_openidc).
I am just wondering how to implement this on the WSO2-IS side, as I don't find documentation.
*bonus: we also hit several errors while deploying WSO2 (SQL errors) and using it (https://wso2.org/jira/browse/IDENTITY-3009) which made us a bit distrusting about the product.
Oauth2 token validate may be performed with a SOAP call to
{WSO2_IS}/services/OAuth2TokenValidationService.OAuth2TokenValidationServiceHttpsSoap11Endpoint/
The response will include details regarding token validity and JWT claims.
I'm working on an command line utility that requires access to a backend server over a REST API.
I'm trying to avoid implementing my own authentication mechanism and use one (or more) of the public auth services (like google, Facebook, amazon).
I am trying to make the client accept credentials and authenticate against the authentication provider and do that without asking the user go open a web browser and provide back a token. The client will be open sourced in order to avoid trust issues (i.e. the user credentials are not sent to my backend server).
I am not interested in authorization, I only care of authenticating against my backend server without having the user keep yet another set of credentials (and without sending the user credentials to my backend server).
How can I have my client authenticate with the auth provider and get a token to communicate back with my server without having the user use a web browser?
I realize you said "not open a web browser", but what about if that browser is on another device (e.g. their mobile?).
If that is acceptable, you can use the OAuth 2.0 for Devices approach, whereby you present the user a short alphanumeric code, which they enter on http://google.com/device to authenticate the request from another device. This OAuth flow is designed to work in environments which don't have browsers (like a command line).
To see a demo of this authentication flow in action, visit the YouTube TV site, press the ← key on your keyboard, and select Sign In.
It's also easy to try out yourself – create a OAuth client in the developers console (of type "installed application" -> "other"), and follow the curl examples in the docs (be sure to replace the demo code in the token request with the device_code received from the initial request to the code endpoint). Decode the resulting id_token using any of the example JWT decoders, like this one.
In your case, you should request the profile scope, which will return an id_token in the response to your token endpoint call, from which you can extract the user's Google profile id (the id token's sub field).
Using this example eventually I would like to send the data to my server. The question is: if someone would break client script, replace email with some other email and sand it to my server? How can it be prevented? also, according to oauth standards I should verify the data on server side using client id and secret key, but I don't see any documentation regarding that in this particular related documentation.
You would not send unprotected data from the client to the server but you would send the access token that you've used to obtain the user info to the server side so the server side can retrieve that data from Google on its own
You should be using what Google refers to as the Server Side Flow (which is really more of a hybrid flow, involving both client side and server side components).
In this setup, you use the Google+ Sign-In button to navigate the OAuth handshake, but what comes back includes a very short-lived one-time-use code. Your client then sends this to your server, which exchanges it with Google's servers for an auth token, which can be used to get the email and other user information.