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
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.
I've added kGTLRAuthScopeDrive scope to OIDAuthorizationRequest and I am facing the issue shown in the picture below:
How can I verify my ios app?
OAuth Client Verification
Starting July 18, 2017, Google OAuth clients that request certain sensitive OAuth scopes will be subject to review by Google.
Add-ons, web apps, and other deployments (such as apps that use the Apps Script API) may need verification.
You must apply to have your application verified by google before others will be able to use it. Verify
By clicking advanced you should be able to login yourself as the developer who created it. this is used for testing only
I have went through the OneDrive API documentation but couldn't find anything on what I needed. Basically, we have developed two apps, one webapp and one mobile app for our product. We want to share the tokens between the two apps (if the user has already authorized for one app, he shouldn't need to re-authorize the second app).
The API settings page in Microsoft Account Developer Center states that
Mobile client applications use a different OAuth 2.0 authentication flow.
What is the recommended way to achieve this in OneDrive? Can the two apps use the same client id/secret and share the tokens? Or can they use different id/secrets and OneDrive provides a way to sync these tokens?
You can not do this since the registration for web apps are different from the mobile app. You can do this if both are web or mobile apps.
When registering an app in Azure AD, the first option is to specify is your app web or mobile app, and then the flow and settings will be different based on the selected app type.
Hope this helps.
We already have a web app that integrate with differente Google services. Right now, you can loguin using a Google account, can import a contact lists from any Google account, and can sync a Google Calendar with our Calendar in the webapp (We implemented all of this using OAuth 2 and invoking the GoogleApi with a REST Client).
We are now trying to publish this app in the GoogleApp Marketplace, but we are failing to comply with the "Use one-click single sign-on" rule (https://developers.google.com/apps-marketplace/practices#5_use_one-click_single_sign-on).
We are believing that the problem is we the way we are solving the fact that we need offline access for all the integrated users in the app. Right now, the only way we found to get the refresh tokens for them, was starting the OAuth2 process with the parameters access_type=offline&approval_prompt=force, but this forces them to enter their credentials.
We aren't using the 'Google+ Domains API', and we are starting to believe that we should. Is the use of this API mandatory for complying with the "Use one-click single sign-on" rule?
Thanks,
Well, we finally figured it out. We had to use the Google Admin SDK in order to implement SSO. We had some troubles with the scopes, but after we polished that, everything seems to be working OK.
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.