how can i make my access token valid across multiple servers?
So here's the scenario:
We have an SugarCRM application installed behind a load balancer with a round robin configuration. We're using oauth acces token for 3rd party vendor authorization in our CRM. The 3rd party vendor is sending multiple requests to CRM using the same token. The problem is that the token that is generated from app server 1 is only valid in app server 1. Any requests using the same token and sent to app server 2 will become invalid.
Related
Please forgive my ignorance on this topic. I've been a developer for a long time, but there's a huge gap in my knowledge and experience when it comes to authentication & authorization protocols and proper handling of tokens.
We've got a whole homegrown suite that consists of:
4 web apps (2 in Ruby/Rails, 1 in Elixir/Phoenix, 1 single-page React)
1 image server (serverless app written as an AWS Lambda / API Gateway)
1 custom data API (also serverless Lambda / API Gateway)
We also have an Amazon Cognito User Pool connected to our backend identity provider to authenticate users and generate tokens.
All but one of these allow some form of anonymous access; the other is only available to logged in users. If a user is logged in, they all need to access the user's profile info from the ID token, preferably without initiating another auth flow. Our backend apps may also need to make use of the access token, but obviously we wouldn't be handing that out to to the SPA or public API consumers.
My first thought is to store the tokens in a key/value store on the backend, and have a short-lived, encrypted JWT containing a unique session ID set on the shared domain that all of the backend apps have access to, with the key stored in a config secret. By decoding the session ID, they can get what they need from the data store. The API would also refresh when necessary.
I also know that API Gateway can use a Cognito user pool as an authorizer, but I'm unclear how I would make that work while integrating it with the rest of our apps and requirements above. Sometimes requests to the API are made from the browser (in the React app, for example), and sometimes they come from the backend of one of the web apps.
The image server and API are used by our apps, but are also documented and accessible for other people to build their own applications on. But they would have to register their apps as OIDC clients to receive any profile info from logged in users.
I'd love some advice on how to make all of this work, or at least pointers toward resources that might help make it less dizzying.
I have an OIDC server setup for authentication and authorization. And I also have a desktop application which is essentially a browser with some extra functions.
The application makes calls to a API server directly and the embedded browser visits a web application that also makes requests to the same API server. Everytime the application is executed, user is required to login once.
Should I use hybrid flow? Can the tokens be shared between the app and web app?
I would also like to know how does the Facebook mobile app do authentication with its native part and web view part.
Edit: the web application is a server side MVC application
If the web application is an SPA, and thus a public client, then you can simply use the implicit grant type and pass the access and ID tokens from the embedded browser to the native application.
But assuming the web application is a server side application and thus a confidential client, then you would most likely want to use the authorization_code flow as the basis, since it will give you access to a refresh_token if needed on the server and you can rely on the Authorization Provider's TLS certificate for trust.
You can now choose whether to render back the access token from the server to the frontend, or to use a hybrid flow as you say. The latter would allow you to already pass the ID Token and access token to the native application without waiting for the backend call to the token endpoint and the page refresh to complete.
However, when processing tokens client side you must verify the ID Token signature and match the access token to it via at_hash since you can't rely on the TLS certificate of the token endpoint in that case.
I have a web app that exposes an api using devise_token_auth. I build multiple mobile apps that talk to different facets of this web app over https. They use devise_token_auth to get an access token, and then the access token is used in future requests.
I want to avoid the case where others create their own mobile apps that talk to my web backend.
When a call is made from the mobile client, it uses a user and password who has already signed up on my server to get an access token. How do I preclude others from creating their own mobile clients?
Option 1: I could create a secret api token, and use it on the client and server, where mobile client passes in the api token and the server only accepts the requests containing the api token.
Problem with option 1: anyone who sees the request on the wire can now create a similar request with the api token, and use the api token to make the same call.
Option 2: I make my web server an oauth server, where my app uses oauth to authorize client requests only for my own api user, and rejects other requests.
Problem with option 2: I don't know enough about oauth to know if it works this way, and how to implement this in addition to devise_token_auth - this effectively means two credentials are checked on the server - the oauth verification of the api user, and the devise_token_auth verification of the actual user.
I did look at this and this related questions, but they are not exactly my scenario. The recommendation in those threads seems to be a) that https + basic auth is enough and oauth is unnecessary, and b) blocking ip addresses that are unauthorized (Problem: I don't know how to detect which ip address is my mobile app users' and which is someone else's). c) Another insight from those threads is that if I stored some private secret key in my mobile apps to use to identify the app, they are likely going to be exposed since mobile apps (at least on android) are fully reverse-engineerable.
Any suggestions on how best to design/implement this? Is just https + basic auth sufficient?
I would be happy to share any code (since SO usually expects code in the question) - but honestly don't know what code to share here.
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.
For example: http://www.behance.net/dev/register
requires website name for registering desktop app, but what could possibly be the website for such app??
How to register such non-browser based app?
That URL requires credentials so I cannot see exactly what they're requesting, but it probably wants the application's redirection endpoint.
In OAuth, client apps not only reside on a resource owner's device, but they must also operate a server that knows how to participate in one or more of the OAuth grant processes. The point of requiring a redirection endpoint is so the access token can be transmitted from the authorization server to the client app's server without exposing it to the other applications running on the resource owner's device.