I am developing a web app that will be working with other companies web apps. Part of the desired user experience is that users on our web application will be able to log into our app, and be able to visit our parters' web applications. Accounts will be automatically created for the users on our partners' sites. We'd like them to be able to enter the partner sites already authenticated, without having to log in or authorize anything (like with OpenID or OAuth), similar to the relationship between a bank and a credit card rewards program. Is there an existing standard that covers this?
Single Sign On often used for such functionality.
There are a lot of implementations.
I used in production Jasig CAS
Related
We want to integrate into many different APIs so that our users can import their data on other apps into our app or do actions on their other apps when triggered on our app.
Plain API integration.
However, integration process takes too long for many services and you have to fill lots of forms. You have to submit a request to that platform, they check it, then publish in a few weeks or months. Doing this with many different apps can take months.
I just want to delegate the authorization process to another service. For example, https://auth0.com/ can authenticate users on their platform. This way, you can just use Auth0 and users can sign up to your app from hundreds of different apps. I need something similar to that but I need the access token.
Whenever a user wants to integrate another app to our app, I will redirect the user to that intermediary service and it will handle authorization and return us the access token.
Is there a service that can do that? Is this allowed by services like Google or Microsoft?
One platform I found is apideck.com
Handles authorization process instead of you, your users can see which apps they integrated over their panel or widget.
Allows you to quickly connect to tens of api services.
TL;DR:
We need JWT Auth on an API that is customers specific
Each customer has an API.dll in their own application pool and site on IIS
We need 3rd party BI solutions to be able to securely call the API
We need single users from the customer database to be able to call the API with their existing username and password
Details
At my job we have created a somewhat simple rest API we need authentication for.
The thing is, that the API is not shared between customers. So each customer gets a DLL that is set up to read/write to individual databases.
We would like our API to be usable by 3rdparty systems that our customers use, e.g. BI solutions - as well as user login (the specific users of our system).
Current setup
Each customer has their own: database, application pool, site, desktop app and api.dll (running on IIS)
Customers are free to create any number of users in our desktop application and grant these users varying rights. These users are not centralized across customers. So we have no information about a customers created users (unless we look in their database)
If the customer is self hosted they control the API and the authentication on their server.
If we host their solution we create an active directory user for that customers API and enable basic authentication for that site, granting permission for that single user.
Question
How can auth be set up for this somewhat weird situation, allowing single user authentication as well as allowing 3rd party integrations?
As I understand from my reading we need some kind of hybrid between grant_type: password and grant_type:client_credentials.
As with anything job related, time is a huge factor, but I want the solution to adhere to standards and best practices as closely as possible.
I'm building a web app using Clojure and ClojureScript and I need it to have authentication based on a white-list of organization. For example, let's say I've added University1.edu to my white-list, and when a student from that university wants to login to my web app, they would be redirected to their own universities login system. After that I would just a confirmation of whether or not they successfully logged in there and maybe create a session, cookies, or or something for them.
Is that possible and if so, how can I implement that?
Some common ways to implement this authentication schemes are OAuth2 and OpenID, which are commonly used in websites were you can log in with your social / Twitter / Facebook / Google account.
Using OAuth for instance, you register your website in some developer portal (depending on the service that you'll use to authenticate) and obtain a token that that you'll use during the login flow and after logging on their portal, users are redirected back to your site.
In order for this to work, every organization (eg. University1) needs to be a provider of this authentication scheme, so that's something you'll need to research.
In Clojure there is a couple of options: the buddy library seems to be a popular choice, but you could also use some Java libraries through interop.
I have a web application where user is authenticated against credentials in DB. Now a days i see the sites incuding SO that allows
users not create new credentials but use the existing credentials with sites like facebook,gmail,yahoo etc.
Can anybody brief how it is done technically so that it helps me to understand should i proceed in this direction?
I came across that it is done using OpenID but that is just protocol. If i want to allow my site to use facebook credentials, do i need to purchase
some OpenId implementing product and contact sites like facebook,gmail etc.
I recently started a new project using different carefully-chosen technologies, my project is built as follow :
The approach is API-Centric, which means I'm building a website and an iOS app communicating with an API written using Symfony2. I've successfully managed to write my API, and it is perfectly working.
To gain access to the services provided by the API, the main actors (the website users, the iOS app users and the developers) can authenticate theirself in several ways :
Clients can gain access with a login/password couple through the website interface which is communicating directly with the API through AJAX to validate the provided credentials and set a session. So, when someones logs in our website, they have automatically access to the API as well.
Developers can authenticate theirself through the API using HTTP-Basic over SSL, which will as well generate a session and give them access to the services they are authorized to call.
Also, Developers and clients can gain access to the website and the API using their facebook account through the Facebook Connect functionality. This deletes the step where each actor has to create an account on our website.
So basically, the credentials are provided either through HTTP-Basic or using the Facebook Login functionality.
Now that my authentication system is working and that my clients are able to access the website, I would like them to connect to a real-time server when they log in. Like in Facebook or Google+ if you want where the real-time server manages chat and push informations.
In this case i'm using Node.js and the powerfull socket.io library to manage everything that deals with the real-time side.
Of course, the real-time service will need some credentials to authenticate the user since he is authenticated to the Symfony security system with a session but is not authenticated against the real-time server.
A solution I've been thinking about would be to use the PdoSessionStorage in my API (Symfony side) and store all the active sessions in a database such as MySQL or PostgreSQL. Doing so, I would be able to send to my real-time server the session id generated by symfony and check on the database if the session id provided is correct or not. If he is I'll let the user access the services provided by my real-time server and associate his session with an identity.
But I really don;t know if this is a good solution and I would like some more experienced advices on this and on how to deal with this issue.
Note : For some reasons, I cannot implement OAuth even if it could be a solution to solve this issue using a Single Sign On approach.