Our application can show rich links to webpages. So instead of a mere weblink we show a short summary and a picture. We used to use embed.ly's extract api to supply us with this data, but since they have changed their terms and pricing we have implemented an alternative solution.
The problem we find is that linkedin profile urls cannot be assessed by our new solution. Embedly was able to give us all the details we needed from a linkedin profile url (including the user's picture), but we don't seem to have access to that information without going through linkedin's API.
This call gives us all the data we are looking for:
GET https://api.linkedin.com/v1/people/url=[PROFILE_URL]:(id,email-address,first-name,last-name,headline,summary,formatted-name,picture-url,picture-urls::(original),site-standard-profile-request,public-profile-url)?format=json&oauth2_access_token=[TOKEN]
Where [PROFILE_URL] is a linked in profile url and [TOKEN] is the oauth2 access token.
There are two issues that I have:
Our application does not ask users to authenticate through linkedin, so we do not have a user oauth2 access token available;
Linkedin's suggestion in their FAQ (https://developer.linkedin.com/support/faq) seems very daft:
Can I get an access token for my application that doesn't require a member to login?
We do not provide access tokens for applications that are not associated with a particular LinkedIn member.
If your application requires you to make API calls in an automated way - without user interaction, you need to bootstrap the first access token request by manually signing in, and then ensure that your application refreshes the token automatically prior to expiry to avoid the need for additional human authentication.
Now... four questions:
a. Has anyone implemented option [2] in a production setting?
b. If yes, what are the limitations, downsides etc. Is this really the best and safest solution?
c. Is there any alternative that allows me to authenticate the application itself with its mighty client key and client secret?
d. Is there anyone from linkedin monitoring this? If yes, can you contact me?
Cheers, Raymond
Related
Note: This is the first time I'm trying to implement a social login API, so thanks for bearing with me and helping me out!
I am developing a web application and I have a login and registration system already developed. Now, I am thinking of adding Facebook and Google+ login - with a backend. I went through their docs and other tutorials and they require to implement considerably a lot of things.
But, since I have a registration system already, I thought of doing something like this:
Have the social login buttons on the login page.
When the user clicks on a social login button and authorizes the app, the user data is returned from Google+, for example.
Now, instead of proceeding with the OAuth procedure like getting the user ID, secret ID and contacting their server from my server for token verification and getting data, is it possible to just use the data returned (after the user authorizes) and do the normal registration with the registration system that I already have?
These are the advantages that I see in doing this:
No need of extra code or database fields like token ID, etc.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
I know the advantages are the same when following the full OAuth2 implementation, but what difference does it make?
Now my questions are:
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
The system proposed by you has certain flaws, especially security related flaw. I would give you to the point answer:
You will send data from client after getting it from google+ or other provider and use your registration process implicitly.
This approach is wrong as I myself as an attacker can send you the data from google+ using my clientid for an app. Will you register or login using the info I am sending? I can pretend to be anyone in your system if you do that.
Is it OK to cut short on the social login as mentioned above?
Will I be losing any obvious advantage doing so (given that I already have a registration system in place)?
If yes, is anyone else cutting short on the flow in their website?
No. (see the reason above).
No. You won't be losing advantage as you already have system in place. Most of the sites have a system in place for normal registration. They give oauth login by leveraging it. Some will say that the password is cumbersome or such, but all famous sites provide login and password including SO.
Now the question comes, how to simplify the oauth system given that you already have a system in place.
I recommend this(I would assume Google as a provider) flow with things starting with dot are what you need to do:
You have a Google login button.
User click on Google Button.
The User is redirected to the Google site.
The user gives you permission.
Google redirects and give you a token.
You can now send info and token to your server. (You need to send only token as backend will get info. Otherwise, a user with valid google+ token for your website can send you any info).
Backend verify token and match that "aud" is equal to your client id. Or it can happen via a library. You will need to give only your client id.
Backend get profile info from token in case of Google+(Name, email) while verifying which you can store as part of your registration process or login process if that email already exists. You can store google id of user also. This is useful as some provider like fb don't always provide email for every account. (For some fb don't give email but for majority of cases it give you the email.)
Backend send back session info or jwt token or any other time bounded process which tells that the user is login.
Your user can login via email also. If he isn't already registered then, then he will need to register. Otherwise, using forget, he can set password or from accounts settings he can set password.
You also need to be careful if the same user is connecting via a different provider, he need to have the same account in your system which you can handle via email.
Kevin,
Authentication is a complex procedure involving lot of measures to ensure security. Hence Web-application/ App developers, delegate this critical piece of work to Identity providers like Google, Microsoft, Facebook etc. These Identity providers are trusted by the app developers and more importantly the consumers trust them too.
Why do app developers provide third party/ social logins? Because, it gives the users of the app some advantages.
They don't have to create new account with the app and remember the new set of credentials. Instead they can use the same credentials they are using with the Identity provider, to gain access to the app. This is huge.
They don't have to trust the app completely, means how the sensitive information like passwords, security questions are handled in the app, as they are not providing any sensitive information directly on the app. Only needed public information is fed to the app from the Identity provider. This is huge too.
No need to worry about the system compromise and leak of sensitive information as all Open ID providers have better security policies in place. This gives consumers a high degree of confidence when using your system through third party logins.
"All the advantages you mentioned will be great for the app developers
at the cost of disadvantages to the consumers of the app."
Lets put the consumer disadvantages on the side and look at the advantages you mentioned:
No need of extra code or database fields like token ID, etc.
You still need code/setup to validate your own tokens. You have to add more logic to verify the external tokens, but the consumers will have the advantage of using the external providers like they are in any other application.
User can add a password to their account whenever they want and login to the site or access their account by logging in through Facebook or Google+ given that they use the same email ID.
This is little confusing as users may choose external provider, so they don't have to remember a new password. Also, the account validation process is different if you use external login vs id/password login. If you are willing to provide both, then you already have the system in place, to verify the account for external logins. Then your first advantage is void and you are better of using Open ID spec.
It's enough to use the social login providers' API once - the first time the user logs in (which technically registers the user to the site).
This approach adds confusion to the flow for consumers. They expect to see a login screen from third party provider for authentication (when they click on google+ or FB), but instead they see your login screen.
Instead of cut short approach, it would be worth to use the complete flow. You might add more logic to handle the token verification with external providers, but, actual complex logic of token validation is delegated to the external providers. This adds no confusion to the end user and they can trust your application easily through social id providers. Even though, users can authenticate through social Id providers, it is always a best practice to have the profile object of that user in your system (without the sensitive information like password).
Since you have your own registration process in place, this may not be a huge advantage. But, please look into the open source implementation of any of the Security Token Service (STS) providers, to see if you can borrow some of the features for validation external providers.
Please let me know if you have any questions.
Thank you,
Soma.
Currently using the Provisioning API that is being depreciated April 20.
This is the current flow:
user (University Alumni) gets to our site http://alumni.columbia.edu/email
they click on Create My Account
they authenticate through our university WIND system using what we call their UNI
they land on a page mentioning that an email account UNI#caa.columbia.edu is ready to be created. They can pick an alias to UNI. They also need to enter a password to use the Chat and POP-mail features of Gmail.
they confirm the creation of the account. At this point the API is being called using https://www.google.com/a/feeds/, some data (email address, name, id) being saved in our database.
To log in, they come through our site, click on the login button, this will use the SSO and they get logged in.
Based on the flow above, do I need to use OAuth2.0?
Yes, you will need to authenticate with OAuth using the Installed Applications approach to do this. Instead of step 5 the way you currently have it, you'll need to call the API from a process on your server with an account that has (limited) admin credentials that can create the account with the Directory API. To do this, you'll need to persist the OAuth token information that the account will use to connect, and handle the code to refresh the token when it has expired.
The first time you run your code you'll need to manually authenticate that account to get your application the appropriate permissions so that they can be stored.
If you're hoping to not go too crazy with handling the authentication side of things and you're using .Net, I'd recommend checking out my project gShell that acts as a wrapper for the authentication and handles the token storing and refreshing for you. It's still a young project but it should fit your needs. Alternately, feel free to browse the code for an example on what to do.
If you plan on using Python, check out Google Apps Manager by jay0lee which is also a wonderful resource.
ok, I've spent 2 hours googling on what it is & how to use it in a web-application! but no success.
Most of the links talk about scanning codes or entering some key in the GoogleAuthenticar mobile app and it'll return changing verification codes every 30 seconds.
Few things :
The webapplication has it's own login. That means users don't login using Google into the webapp.
If an attacker gets the user's password, he sees the QRcode as the next-step, which he can scan directly with the GoogleAuthenticator app in his mobile (as far as it appears to me). How is it tied to user's mobile only ?
In various sites, it mentions a shared secret between user & server, that means at the time of signup, we provide the user the shared-secret, which he can use in her mobile GoogleAuthenticator app and then use it while reading the QR code ?
In the above case, how to proceed if the secret is lost or forgotten by the user ? Use forget secret to send the secret again to user's email ?
I am confused about how can it be implemented in a fashion when it's a non-google non-android application!
All I get is that, it's just a concept asking for our own implementation with some help from the source-code of the GoogleAuthenticator. Please correct me ?
What I think is the solution is that, we have to write our own mobile-app, just like this guy mentioned here, although I'm still not sure how will the secret between the mobile-app and the server will be unique with each installation of that app such that it identifies a particular user only or is there any way to write our own app and use GoogleAuthenticator mobile app without having Google-login in our webapp ?
Google Authenticator (the mobile application) implements the Time-based One-time Password Algorithm. In the scenario you are asking about, two-factor authentication would work as follows:
The user generates a one-time password to be validated by a server application.
The server would verify the password using the procedure detailed by the TOTP algorithm.
The password generation on the user device can be performed by any application implementing TOTP which has been "configured" for your user account. Configured here means having shared a secret with the server, as you mention yourself in the question.
Now, trying to answer your questions:
The fact your application uses its own set of user credentials or Google's has no direct effect on two-factor authentication. No matter what these credentials are, you need a way to identify your user (the username) in order to be able to proceed to the validation of its TOTP password, because you need to know who the user is. Said another way: using TOTP and using the Google Authenticator application does not imply having to use Google credentials on your site.
I'm not sure I understand correctly. The configuration of the Google Authenticator app for each account is performed only once. If an attacker is sitting right behind your back and takes a photo of your screen while you configure Google Authenticator, then yes, he'd be able to configure its own application with your credentials reading the same barcode you're using. Nevertheless, he'd also need your credentials (proper) in order to perform the login and then provide the one-time TOTP password. Anyway, this is a security problem which stems from how the user improperly handles its own credentials and you could be subject to similar problems no matter the technology you use. To make an imperfect metaphor, it's like asking "if the user leaves the pin card with the codes on the table, an attacker sees it and steals a photo of it, could it use them?". Sure, he could.
Yes, reading the barcode is one of the ways you can configure the application and sharing the secret between the client application and the server. You can use other means, such as entering the key manually into the application, but using the QR code is quicker and much less error prone. You won't even need to generate the QR code, because you could use Google's Web APIs as I explained in the blog post you were reading when you asked me to answer this question. In fact, the Java server side library described there uses the Google Web API's and returns you an URL for the user to check out and read its own QR. If you want to build your own QR logic, go on, but there's no compelling reason you should do that if you're eligible to use Google's APIs (which is something you should check anyway).
If the secret is lost it depends on your own policy, if it's your own application. First of all, you should invalidate the old secret immediately upon user notification. Then, you could use the scratch codes you may have given the user upon creation of the TOTP secret to verify his own identity. If he has lost the scratch codes too, you'd probably want to fall back to some other ways to verify his identity such as using some kind of backup information in his account (backup telephone numbers, security questions, etc.). Once the user identity is verified according to your standards, you would issue a new credential and would begin from the start: that is, reconfiguring the Google Authenticator using a new QR and/or a new secret key.
To summarise: yes, you can use the Google Authenticator application as your client front-end if you want to: there's no need to build another one. The only thing which you should into account is that Google Authenticator uses 30-second windows in its TOTP implementation: the server side logic verifying the TOTP password will have to use the same window size (which is, IIRC, the standard value proposed by the TOTP RFC).
Let's say I am making a sign up form in which I asked user's twitter ID. How do I verify if the ID entered by user belongs to him/her? In case of verifying email we simply send a verification link which user has to click so how do I verify twitter ID? I have never used twitter before.
The only reliable and practical way to verify that twitter account X belongs to user Y this to do full on “3 legged” OAuth authentication. That being said, you may want to consider if you might be OK with just taking the user at their word on it.
Getting OAuth to work and securely storing the resulting tokens is much easier nowadays than it once was, but is still non-trivial.
Reasons to verify the twitter account, in increasing reasonableness:
You will be making enough server side requests, on behalf of multiple users, that you run up against Twitter’s API Rate Limiting. (Having multiple auth-tokens will allow for a higher API rate)
You need to automagically send tweets and/or follow accounts on the user’s behalf
N.B. do this as opt-in and be ultra clear about when/why you will be doing this, or you will face the justified fury of scorned users
Don’t verify the account if you’re looking to do these things:
You need to send tweets and/or follow accounts on the user’s behalf, and the user will be able to perform a browser based confirmation workflow for each of those actions; use Twitter’s Web Intents for this.
If you just want to pull in real time data for user’s avatar, bio, or recent Tweets Twitter supplies some prefab widgets for you.
All of the authenticated Twitter API Calls can be done client side with JavaScript. Twitter has a js framework, which does not require you to handle and store tokens on your server, to help you with that.
An alternate contact method for password resets, notifications, etc.
Private communication between users on twitter requires mutual following, many users probably never check their Direct Messages (or even know what a DM is), and any messages would be limited to 140 characters. Just use email for all that kind of nonsense.
If you’re just gathering this info to display it on a user’s profile page, in an “other places on the web” kind of way, integrating and maintaining all the server side OAuth pieces is likely too much bother. Just make sure you have a reasonable and clear TOS and an obvious way for 3rd parties to report any of your users who may be claiming a twitter account that is not their own.
If you’re still interested in OAuth, Twitter's Dev page has plenty of resources, including a nice overview of a generic “Sign In with Twitter” “3 legged” OAuth work flow.
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.