I was just wondering, I want to associate a Twitter and LinkedIn account with my systems accounts. Which would allow them to post to interact with them without needing to log in to the other systems.
Is there a way to store the social (twitter / LI) usernames and passwords and associate them with my system and vis versa.
E.g. If I login using my native details (email / password) I can access the API features of my social network accounts?
Thanks in advance,
Chris
I can't speak for Twitter, but with LinkedIn you could follow this basic workflow:
Register an 'application' with LinkedIn. Your site will use this application for all communication with the LinkedIn API.
Have the user authorize your site (your application really), to access their account via the LinkedIn API.
Retrieve the user's unique LinkedIn ID, as well as their access tokens, and store those in your user account database, associated with their existing account.
Then, when they return and log in to your site, any calls you need to make to LinkedIn can be done via the stored access token, rather than having to have them manually allow you to have access again.
Related
Currently, I have Google, Github, Twitter account registration/login (merge them by email). But I want to give a currently logged-in user ability to manually connect another social account (with a different email). For authorization, I use JWT and store them in localStorage on frontend.
The problem comes when we redirect user to some of social login providers and when he returns back we don't know who it is. It can be user that connects an additional social account to the main account or a new user that firstly login by some social provider.
What possible solution for getting logged-in user after redirect from Social login provider when using JWT for auth?
or
What best solution for linking social account to existing main account when using JWT for auth?
By "social login provider" I mean Github, Google, Twitter, etc
Ok, I just create separate routes for connecting and store JWT in cookies to ease auth check.
I get it that Oauth is used to grant permission to a third party application to access a user's data (like photos on his facebook account) without revelaing his facebook credentials to the third party application. For example, when you try to use an online photo editing tool and you want to load a photo from facebook, facebook will pop up a message asking whether you really want to allow the application to access your data. So at that point facebook just returns a temporary access token and the app can use it to access your facebook photos. (as i understand the scope for this access token is such that it only has permission to access the particular user's photos only) Yes, this sort of a setup is required because you can't trust a third party application that much as to give away your credentials.
Assume somehow instead of oauth, facebook used api key authentication. This would mean that all third party applications that have subscribed for facebook API already have a key which they can use to access facebook's data sources.So that the app can directly take you to your facebook photos and facebook will not notify you that an outsider is trying to access your private data. This approach is not suitable for an api that exposes user sensitive data but for apis that expose not so user specific (like google maps) data, the api key approach should be enough, right ?
So my question is, what are the criterion to decide which authentication type should be used ? And appreciate feedback if my understanding is wrong.
Here are 2 of the standard 4 Oauth2 flows which cater for the scenarios you mention.
Authorisation Code
Client Credentials.
Using your Facebook example above you could think of like this:
Use Authorisation Code flow for your "Oauth" scenario, where your app needs delegated authorisation to access a user's Facebook photos. This means the user must login and grant access to your app and your app must have an API key (client ID) issued by Facebook.
Use the client credentials flow for your "API Key" scenario. This would be when your app needs access to, for example, public Facebook pages / info and thus does not require specific user consent and can just use its API Key (Client Id & Client Secret)
I need to build a custom auth system with and i don't know what to choose between Firebase Auth and Google OAuth/OpenID.
I don't want my users to sign in through google accounts nor facebook nor twitter etc.
I want to use my own user database to authenticate my users.
So what is the best and more secure, reliable,scalable option to setup this ?
Thanks
If you have an existing list of user credentials (e.g. Active Directory, LDAP or a database with user names and passwords) you can authenticate those users yourself and then tell Firebase about them with Custom Authentication tokens.
Using Google authentication makes no sense in that case, since the credentials you have are not for Google accounts.
So I am creating an application for my google apps domain. It will have its very own google apps account associated with it, from which it can store/retrieve/manipulate data.
The application should use this google account alone and the user should have no indication that it is using a google account. Is there a way to programmatically authenticate my entire application and not prompt the user authenticate/authorize?
I think you are looking for two legged OAUTH.
You can generate a OAUTH token and secret in the control panel of Google Apps and assign the authorized scopes to this token/secret pair. For instance, you can authorize access to the calendar of all users in your Google Apps domain using the token/secret.
You can then programmatically access the calendars of all users.
Because this token/secret is authorized by the Google Apps domain administrator, individual users do not need to grant access anymore. That is why this is called two legged Oauth, whereas three legged Oauth requires user interaction to obtain a token/secret for an individual user.
This question on SO might interest you too.
Should I use oAuth, for example LinkedIn or Twitter, as my signin mechanism for my app? It seems that most apps just use oAuth to connect other services to it, but they make you set up your own user/password after you use oAuth (including StackOverflow), and I'm not really sure why this is. Would love some insight here. Thank you.
Why not use OpenId, to allow people to sign into your application, without having to type any specific login/password ?
Quoting the corresponding wikipedia entry :
OpenID is an open, decentralized
standard for authenticating users
which can be used for access control,
allowing users to log on to different
services with the same digital
identity where these services trust
the authentication body. OpenID
replaces the common log on process
that uses a login-name and a password,
...
BTW, that's exactly how one logs-in on stackoverflow ;-)
OAuth purpose is not authenticating your users with your site, is letting your users allow you (the oauth consumer) access to their protected resources in other sites (oauth providers) like LinkedIn, Twitter, Google APIs etc.
For authentication, you should use OpenId as others have pointed
Twitter provides a Sign in with Twitter flow that is OAuth but provides a faster redirect if it is an existing user of your service and they are already authenticated with Twitter.
http://apiwiki.twitter.com/Sign-in-with-Twitter
If you are building a Twitter centric application this makes a lot of since to use and you won't have to implement an entire alternate authentication method like OpenID.
Be careful if you let users authenticate with both Twitter and LinkedIn as users will inadvertently create two accounts and need them to be merged.
Facebook and Twitter both have the "Login with Facebook/Twitter" APIs to actually allow users to login without having to create an account for your website. Both of them will return you a valid session that may (or may not) expire. So you actually wouldn't have to ask users to decide on a username/password, as you can fetch both from the APIs (you can not get the users email address when using Twitter though)
So why add those functions to your website?
Users are in general more likely to hit the "Login with ..." button than going through the whole mail address authorization process and entering their name, etc...
Linkedin only has OAuth for usage to its API. It will also depend on what type of language you are writing your webapp in, they should have premade wrapper libraries you could tap on to.