In general, what's the best practice to authenticate a user via 3rd party (say Twitter) using iOS's ACAccountStore and then tie it to an existing user in my own service assuming that they were logged in already? Can I access and store the account credentials remotely over ssl, or is there a better way?
And if they had to re-login via Twitter, I could just search for the user with that twitter handle to know what backend user is tied to this account, yes?
And lastly if I wanted to be able to login via a browser later on, I would get new oauth credentials for the webapp as well, but could search for a user with the same Twitter account info and store these credentials as well, and know that they all refer to the same person, correct?
What you're asking involves many levels of a system "stack" that are custom to a particular environment. What is "correct" vs "incorrect" is dependent upon the environment you've set up and are connecting to from your iOS app.
So from what it sounds like you're leveraging iOS's Twitter functionality to create a Single Sign On (SSO) experience. There are several guides on Twitter's site for doing what you want to accomplish:
Integrating with Twitter on iOS: Single Sign On
Using Reverse Auth to Get OAuth Tokens on iOS - you can then store these server-side
Migrating tokens to system accounts - how you get OAuth tokens from your webapp to iOS.
Related
I have my own IDP and user store which is used by other apps in order to allow users to login. Right now i am trying to spin up a new storefront using BigCommerce ecommerce platform , for this app i need to use the existing IDP and user store so that users who are using the other apps can single sign-on into the new store front app as well. Can anyone please help on where to start on?
I also had a look into the big commerce Login API using which once can able to login using JWT token for the customers existing already in Bigcommerce platform, But in my case all my user data are store in my custom IAM and i need to log those users into store front seamlessly.
Thanks in advance
You need to provide BC Login API with a signed JWT. That JWT needs to contain the BigCommerce userId to enable it to login. To create the JWT you will need a client ID that can be created by creating an app in your developer account, thus creating the trust and not requiring credentials, just a userId.
This gives some help on creating the JWT and all the info required within it:
https://developer.bigcommerce.com/api-docs/storefront/customer-login-api
And this is a simple example of it working using Express middleware and Auth0:
https://github.com/bc-simonpallister/bc-auth0-oidc
For BigCommerce Single Sign On (SSO), you can definitely use the following information mentioned - https://developer.bigcommerce.com/api-docs/storefront/customer-login-api
But as I understand, you are also looking for a seamless solution for BigCommerce SSO wherein you can skip the complex coding part.
If this was interesting, here is the entire scoop for your reference -
https://www.miniorange.com/integrations/bigcommerce-sso-mfa
PS: You can also enable auto sync using above solution in case you wish to provision your users/groups in future.
This is a two-fold question in that it first asks a best practice for the situation, then asks how it should be implemented.
The situation: I'm creating a mobile app which operates through an API built in Rails. Meaning, users are created and fetched through the Rails API. The mobile app will allow the user to login via Facebook.
Problem: I'm not entirely familiar with how the Facebook login functions, such as what information should be used to fetch the database user.
Question: The goal is to login via Facebook in the mobile app and it fetch the user's data (or create the user) in the database via the API. So, should I set up the Facebook login on the mobile side? Or the website (API) side? And what information should be passed to/from the API?
I'm doing the same thing for Google+, but once I understand the best method for Facebook, I'm sure it will also apply to Google+ or any other oAuth authentication.
Thanks!
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.
Me and my colleagues developing an application (both web application and mobile app(iPhone & android)), which includes a login process.
Currently, we have our own login mechanism (where users have signed for an account on our app, and have stored their info in our Database). We are looking into integrating oAuth and allowing users to login with Facebook, Twitter, LinkedIn and Google.
Now, when the users logs with any of those, as I understand the login process occurs outside our application and basically only get permission to access their resources.
My question is this: through oAuth, how do we remember users? i.e., users who login have read /write privileges and have preferences. How do we remember those when they don't actually sign up through our app.. Can we store their email address in our "Users" table??
What are the best practices in such a scenario?
Thanks for any info you can provide.
Having built authentication databases for a few different OAuth-enabled web sites, I can say that I've learned a few things that you should keep in mind.
You should have a table of users for your site that is completely independent of which OAuth provider they used for sign-up/sign-in. This enables your site users to combine multiple accounts together under their primary identity on your site. (For example, associate both Facebook and Twitter with you.)
When you let a user sign up, you should get an email address from them. Whether you ask Facebook for it, or if you have to ask directly. This enables you to "upgrade" users later from depending purely on third party OAuth to setting their own password on your site. (You simply send them a link to your password reset page in order to get them started creating their first password.)
You don't want to use email address as your primary key. I'm not sure if that's what you're actually describing or not, but you really want them to have a local user ID that you use for maintaining their session, etc. You then associate their Facebook ID or their Twitter ID with that local ID, and use the correspondence between such identifiers to match up which of your site's users to consider logged in.
I have completed my iOS app and now want to have user registration and authentication functionality.
When the user opens the app it must ask them to register or login and then when the app closes it logs out. I want to send their basic details to my server e.g. name, location.
Is this allowed my Apple and does anyone know of a service that I could use as appose to reinventing the wheel?
It is allowed by Apple.
There are apps on App Store that do not implement their own register/login mechanism. Those apps ask their users to login via Facebook. So any user who has a Facebook account, can login to your app using their FB credentials. You would have to use the iOS SDK provided by Facebook.
It is always better to provide multiple login options to your app user, instead of just relying on Facebook or any other provider. Allow users to login via GMail, for example.
Adding support for OpenID is another good option. OpenID is an open standard that describes how users can be authenticated in a decentralized manner, eliminating the need for services to provide their own ad hoc systems and allowing users to consolidate their digital identities. Users may create accounts with their preferred OpenID identity providers, and then use those accounts as the basis for signing on to any website which accepts OpenID authentication.