We have an existing Android and iOS application that consumes REST API from our servers. The API provides a token to the authenticated users after they log in using their credentials (username, password combo.) from the mobile applications.
Now, we're planning to create a Google Glass application for the same. In this case, we'd like to use the existing REST API along with Glass also. The Glass app will be built natively using the GDK.
My concern is, how would the users be able to input credentials? Because, users may have signed up for the service using non-google accounts?
Many thanks in advance.
At the moment, there is no supported way for apps made with GDK Early Access to authenticate the user or provide a way to connect the Glass account to your auth system. The Glass team has indicated such methods are coming, however - the Strava Cycling app, for example, does this, and it is expected that a similar feature will become widely available as the GDK matures.
Strava Cycling appears to get its credentials at the time you setup the app through MyGlass. When you turn it on it redirects you to a website to log into Strava's service before completing the install.
I just gave a talk on this exact topic at Wearables DevCon. The solution I proposed is purely done through GDK. All the user has to do is sign into their Google Account on a phone/tablet/computer and enter a code that is shown on Glass.
Check out the slides here:
https://docs.google.com/presentation/d/1NepYwlKdEvLV0QH9ix2I8l-JY1kHjBR9AXKBNpgTI6g/edit
And the code here:
https://github.com/victorkp/GlassWebNotes
The latest Glass release (XE16) publishes the remote authentication API for apps distributed through MyGlass:
https://developers.google.com/glass/develop/gdk/authentication
Related
My question is how a 3rd party developer would login users through my Identity Platform? I looked at the documentation but found nothing.
Essentially I want to use Identity Platform as an OIDC Provider, but I don't know if that's supported.
Cloud Identity Platform is based on Firebase Auth product (literally because the documentation and the Javascript to add are still in Firebase perimeter!).
This product allows you to delegate the authentication to a third party, either Firebase auth if you use login/password authentication, or to connect Identity Provider (IdP).
There is several built in IdP like Google, LinkedIn, Facebook, Twitter,... and you can add custom Auth0 provider (SAML) and OAuth2 provider (OIDC).
The platform only allow you to perform an authentication and then redirect the user to YOUR app. Then, it's to YOUR app to ensure the correct authorisations and roles of the user.
All of this for saying to you:
Think about firebase Auth feature: originally, it has been designed to authenticate user that wants to connect to Mobile App, on Android. Today it's the same thing but, in addition, for your web app
It's designed for YOUR application with YOUR roles and authorisations. By the way, if your target is to allow your 3rd party developers to log into Google Cloud console thanks to this authentication mode, it's not possible.
But, stay tuned, awesome things are coming soon on this field
John is right, more details would help. But if I had to guess you are referring to the fact that Google Cloud Platform IAM does not handle Identity part only authorisation. You could, however use G Suite or Google Directory Sync (which can integrate with LDAP server or Active Directory.
You can refer to the link below which shows you how you can integrate with OIDC:
https://cloud.google.com/solutions/authenticating-corporate-users-in-a-hybrid-environment
I am looking for a solution to integrate Google Cloud Identity into an existing project. The idea is that there are two applications - old and new one. Within old application the users are right now logging with username and password, within the new one I plan to introduce GCI.
Is there any way to have backward compatibility with the old application authorization model while having already Cloud Identity established in the new app?
The problem is that user is supposed to be able to authorize both in old and new applications and I can't think of a solution that would not force me to change authorization model in the old application which I would really prefer not to.
After thorough research I came to a conclusion that the best way to integrate classic authorization by username and password with Google Cloud Identity would be thanks to Firebase.
Firebase Authentication supports password authentication in addition to federated sign in with Google, Facebook, Twitter, and more, allowing you to easily scale your authentication system as you grow on desktop and mobile. Apart from that Firebase is also provided out of box when using Google Cloud Platform.
Using Firebase I will be able to implement simple login with username and password in the old app and use Google Sign In within the new app.
Essentially, I'm wanting to create an Oauth Client as an App so I can get data from Dynamics for multiple customers. Does anyone know if this is possible to do in AppSource or do you know of another way?
I have a service that will be served in a cloud different than Azure so there really isn't anything for me to submit as an App and I really don't want every customer to have to setup their own App that gives my service the privileges/access it needs, but it's looking like I may have to.
It sounds like you'll want to register an app with Azure AD (the OAuth2.0 service/identity provider for work and school accounts), and create a multi-tenant app. Then you can configure this app in the Azure Portal to get permissions to the APIs the app wants tokens to call (in your case Dynamics or the Microsoft Graph).
Once this app is written, you can code up your app using one of the Azure AD Auth Libraries. Here's some sample code for a .NET web API. You can find more code samples on Github and search active directory. Moreover, the Azure Active Directory Developer Landing Page is a great place to look for more resources on doing all of this.
My team is trying to develop a product for the google apps marketplace and I am having issues with the workflow in the new ADMIN SDK.
With the now deprecated Provisioning API we simply ask for a username and password from the account we are trying to manage.
With the ADMIN SDK it seems as though they would need to go enable the API, create a key and do a lot of manual work for this to happen. This really is a tough option for us as the technical level of our clients is not likely to be able to make this transition.
Is there something like the work flow for the provisioning API where they can enable management from a third party or a recommended workflow for a developer to build an application that can access any number of google apps accounts?
A use case for this is say I want to develop a different option for a console, I want to build a console web app and simply ask for credentials or easy setup routine and allow our users to manage their google apps account in a different way.
Thanks in advance,
Steve
The Admin SDK Directory and Reports APIs work correctly with 2-legged OAuth 1.0a which is what the Google Apps Marketplace currently supports and automates. You do need to turn the Admin SDK on under "Register for additional APIs" from your Vendor Profile page on the marketplace. Also, the Administrative APIs for the domain must be turned on. You'll get a generic error that the domain cannot use the APIs if it's off in which case you can direct the client to the exact CPanel page where they can turn it on.
I will launch soo a new iPhone app and want to off-load the forums to my actual FogBugz On Demand account.
However, I discover that FOD have no facility to integrate Single sing-on. I use django and have the option to use open-id, but not know if exist a way to make this happend.
Obviously, I could hack a simple forums like the one on FogBugz in django or reuse one, but I just think that aintegrated forum with the bug tracking is the best thing.
Any idea?
FogBugz On Demand now natively includes some authentication methods other than the standard username/password authentication.
Setting up authentication with Google's OAuth is quite simple for companies using Google Apps for work email. Once an administrator enables OAuth following the instructions in this article on Fog Creek Software's help site, logging in is as simple as clicking the OAuth button on the login page. All of the users' settings are retained.
If you’re already managing the rest of your authentication through a SAML 2.0 provider, you can also use your identity provider for FogBugz login. Steps for configuring SSO can be found in this article. This requires a bit more configuration than OAuth, but will work for companies that don't use Google Apps for email.
Of course, if you have any questions about configuring SSO in FogBugz, you can always contact customer support at http://www.fogcreek.com/contact/.
From the FogBugz forum:
http://support.fogcreek.com/default.asp?fogbugz.4.102256.3
I believe this is you there also. The answer provided shouldn't be too difficult to implement.