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.
Related
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
I am wondering if there is a way to login automatically so that the username and password would be hardcoded into the app and it would be used as a way for the user to upload photos without them having to have a Flickr account?
From the sound of your question, you want your app to have a Flickr account associated with it so that users won't have to have their own Flickr account. Then, you want your app to authenticate with this account, and allow users to upload to it. Storing login credentials "hard-coded" is a terrible idea - someone poking around with the app bundle may be able to find the login info - which is why we have OAuth authentication schemes. By reviewing Flickrkit's github documentation, they have an API for authenticating your app. So what you would do is first generate the authorization token for the shared account using your app, then distribute the auth Token that's generated in NSUserDefaults in your application and use that as the auth Token for general distribution.
So...
Your question is kinda broad so I'm not sure this is the answer your looking for but maybe it'll help.
If the user must login then somewhere the login information must be stored as a variable. All you need to do is save those variables containing the login info and when your app loads run your function to login with those saved variables.
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.
I'm trying to build a Google Apps Marketplace App using the new APIs only available through OAuth2. We already have an app using the old APIs, but I'm having trouble figuring out how to have the same flow with OAuth2.
In our old app, the domain administrator would install the app and give it permissions. Then, we could just make requests using our app's id/secret without user interaction. (2-legged OAuth)
How would I do this with OAuth2? None of the flows described here sound like what I'm looking for.
I'm also having hard times to find out to get this new OAuth2 login up and running.
You will have to use service accounts to make requests on behalf of the user.
Documentation is here:
https://developers.google.com/accounts/docs/OAuth2ServiceAccount
I did not yet manage to get the flow working without each user being prompted again, but this most likely is because I need offline access:
Google Apps Marketplace SDK + Domain-wide OAuth 2 SSO
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.