We want to provide a service where the users would have to register in our website. The problem is that our customer (another company, say company A) wants to verify, for security and spam reasons, that each of the users who register are indeed verified users, but they won't let us access their database (where all the users are already registered).
We could do a manual verification (using users physical ID card) but this wouldn't be very effective. That's the reason why we were thinking that maybe we could use something like OAuth or OpenID to make our users sign up / sign in through their account at company A.
Apart from the email/username, we would need to collect some extra information for each user that they don't have it on the database of company A, and be able to use it over time. That is to say, it would be great if we could use company A's database, without having access to it, to verify the identity of our users and allow them to sign up as verified profiles.
What technologies and procedures should we adopt to achieve our goal? We have heard and read about OAuth and OpenID, but we're not quite sure whether that's what we are looking for or which one would fit our problem most. On top of that, we would appreciate if someone could provide us with a guideline for the implementation of the solution, as it's not the typical Facebook/Google Sign in for which there is plenty of information, but we have to use the database of an external company.
Note: we are using PHP and MySQL
At this point, if you want to deal with authentication/authorization you should look at the OpenID Connect and OAuth 2.0 as they are the most recent and the ones with an increased rate of adoption.
They share a similar history because in both cases they are not backwards compatible with the versions that preceded them, more specifically OAuth 1.0 and OpenID.
However, for this particular scenario you'll be dependent on what Company A supports. You can add support to OAuth2 and OpenID Connect to your application, but if Company A does not support it you're back to square one.
If you can in any way influence what Company A will provide to you then a compatible implementation of OpenID Connect would be your best bet as it would allow your application to use it as a way to verify user identities without having direct access to their user database. After receiving a verified user identity you could then require more information from the user in order to have a more complete profile on your side.
Assuming that Company A did provide an OpenID connect compliant implementation integrating with with would be very similar to integrating with any other provider like Auth0 and Google. I say similar, because as you can check in each link each provider may have their own extensions and supporting libraries that aim to simplify the experience.
Related
I am a beginner in php. I want to integrate Teamwork API on my web page. I have already checked how to call different methods of teamwork API and what will be the JSON response of them by using developer.teamwork.com.
Now, I am a bit confused that if I use my API key in the GET request as described on the api documentation then the response contains info related to my account. Actually, I want the user to login to his/her teamwork account through my web page and I will retrieve the info regarding their projects on the web page.
So, as far as I understand, I will need to ask for user's API key of his/her teamwork account to display the info on web page. But then it's not a good approach to solve the issue. Is there any other way? Is it possible that user provide their username and password to login and get the account details?
If you use your own API key, then you will get your own information, the api key is connected to the information they have about you.
The key is a certificate about who you are and that you have the right to see the information stored.
As far as i can see teamwork.com have account and billing information in their care, and i would be worried if they shared that information to anyone without special access, such as the API key.
Depending on what you do i would consider the approach you are using, (unless teamwork have some kind of solution for it), making other people share their api key with you could be considered a security breach that could expose sensitive information, in the unfortunate case where you are not able to keep it secure, or where a customer find's you unreliable and prioritize their security over the benefit of your product.
Correct me if I'm wrong:
With respect to a user's email address associated with their account...
You can ask for and receive email addresses from openID providers (i.e. Google, Yahoo!, AOL, etc.).
You cannot obtain email addresses from OAuth providers (i.e. Twitter, LinkedIn, etc.).
You can receive email addresses from Facebook via OAuth.
If I am wrong and there is a way to obtain email address via OAuth, please describe an easy method.
Well what you have described is almost right.It dependents upon what you want both protocols Oauth and Open-id provides a way to Authentication but Oauth provides a fine grained control.
basically you can get Email address from Google/Yahoo/Window Live using Oauth and as per your analysis Both Twitter and LinkedIn model do not have the option to give back email.associated with the user.
But you need to have a clear understanding of whats different between both of them as that will clear your case what is provided by way
Both work on domain of security, identity, and authorization.
work on the principal of decentralization.
With Open ID, there is no suggestion of two web apps sharing your data. Except in the very limited sense that the Open ID provider may hold some general information about you.but this is data of a generic.
OAuth lets you authorise one website – the consumer – to access your data from another website
In short OpenId is coarse-grained while OAuth is more fine-grained.Oauth proicde a level of security by asking use to provide access to your data to the party who is asking the access and now its in the hand of user to allow or deny while with Open_id generic data will be available.
So choice is all yours.
Which is the simplest and best free tool(php) that provides "single sign-on" i.e login via many sites.
It should provide me basic details of users like name dob, location etc. It should be completely free irrespective of site traffic. It should have facebook, twitter, google
Following are the reliable and/or viable and very simple to implement solutions
https://www.simpleauth.com/
https://rpxnow.com/signup_landing_basic (free basic version)
http://openid.net/developers/
http://www.gigya.com/public/platform/Register.aspx (not free)
If you want all in one, than OpenID is your solution. OpenID's free service is shared service. Users must have OpenID account first to be able to login with this service.
If you don't want shared option, if you want this SSO (Single Sign On) service only for your own use then OpenID provides paid service. It was $0.25 per user last time I checked.
This means if everyday 100 new members will register to your websites (considering few websites, it should be the minimum), you will have to pay $25 every day to OpenID.
SSO is very useful technology. You can either create your own or go with paid services. Free services for sure will be shared. If you want to create your own, security measures must be first priority.
OpenID is extremely well know, or Facebook since it has so many users :)
Facebook... This will become your drivers license of the internet btw :P
I'm building an application which will basically be an interface for my Google Finance account. Several people will use. I have just started to research on how to do this, and one thing that immidiately seems like a hurdle is Google's oAuth system, seemingly designed for the case where each user logs into his account himself.
The usual proceeding as I understand it is that from my web application, the user gets redirected to Google's page, where they enter their information, and then are sent back. I will wind up with an authorized token that I can use to pull the data that I want.
BUT, now, as my application will ALWAYS and ONLY pull data from my account no matter who is logged in to my application, I need to always be authorized and it needs to happen programmatically without the user ever knowing.
Is this possible?
If this is designed to be an interface to YOUR Google Finance account that several people will use, then OAuth is probably not the answer you're looking for.
OAuth would allow your app to pull information from your users' Google Accounts, whereas ClientLogin would allow your application to pull data from a single account.
Check the Google Finance API for more details and examples:
http://code.google.com/apis/finance/docs/2.0/developers_guide_protocol.html#ClientLogin
I have created a website which allows users to sign up for, and use, an online service. To help promote the website we will be have re-sellers who will be offering their own branded services through us. The initial plan is to allow re-sellers to place registration, login, and lost password forms on their own website and use an API created by us to handle these requests.
I have begun outlining how I expect the API to work (and starting documenting it as well) and I want to make sure I get it right, or as close to right, as I can from the beginning as I know once you have declared a public API you want to avoid changing that API at all costs.
So far I have decided:
To have the user pass their account credentials with each request
To require SSL for all requests
What else should I be keeping in mind?
This is a presentation by Joshua Bloch that is a must read for API designers:
http://www.infoq.com/presentations/effective-api-design