I am trying to use the google drive SDK with a metro app. The metro app connects to google drive using REST services. The first problem I am facing is in authentication. Metro app has a redirect URI which follows microsoft specific scheme like "ms-app://s-1-15-2-1527804777-383724396-285855344-2678584489-1963608684-3789894444-799666712/".
How can I register this URI with my Google app profile? Google has made it compulsory to register the redirect URI, I don't know why. No other provider (like dropbox/skydrive) does this.
Could anyone please help?
Thanks in advance.
The redirect URI is part of the OAuth 2.0 spec, which is an open standard and critical to the security of the system. If other providers are performing OAuth 2.0 without this, they are insecure. Worse, if other providers are forcing apps to get usernames and passwords from users, that is bad too.
For installed apps, you can use the Installed Application Flow, with a local web server (localhost URI), or with the "out of band" URI, urn:ietf:wg:oauth:2.0:oob. Having said that, I never tried with a metro device, perhaps others can suggest how to perform OAuth 2.0 on metro.
As per the OAuth 2.0 spec:
When registering a client, the client developer SHALL:
o specify the client type as described in Section 2.1,
o provide its client redirection URIs as described in Section 3.1.2, and
o include any other information required by the authorization server
(e.g. application name, website, description, logo image, the
acceptance of legal terms).
Related
I have a mobile application built upon Ionic Framework which uses many Cordova packages. We are upgrading the app from Ionic3 to Ionic5. In the Ionic3 application our .NET API was responsible to managing user logins. Going forward, in the Ionic5 app we will NOT be managing user credentials - we will be using 3rd party Identity Providers such as Google, Facebook, and Twitter.
We have implemented the Cordova packages to handle external authentication with Facebook and Google and it works fine. How do we tie the token that is received from Google/Facebook to our .NET API? When we try to use the token provided from Google/Facebook we - of course - get a 401 because our .NET API doesn't know about that token as it was issued from an external source.
I am aware of the process of how to enable the schema described here (External Authentication Services w/ASP.NET Web Api) but in this case the user agent browses to the Web Application in the browser. This is not true in my case as the user agent will be using a mobile application not a web site.
But I hope the principal is the same. But I'm missing something here.
The user will open the mobile app, authenticate with Google/Facebook and be issued a token. Now, what needs to happen to get that token to be recognized by my ASP.NET Web Api?
For example. When I registered my mobile app with Google Developer's Console I selected that the type of app is an Android application and was issued a Client ID for Android now how can I use this token in my ASP .NET Web API? There MUST be some way to tie the two together or some article out there.
Thanks in advance for your assistance!
Also, I looked at this post and see its 11 years old. Is there something here that I should be doing? Please help point me in the right direction. how-can-i-verify-a-google-authentication-api-access-token
It is about data ultimately, and identifying users in a consistent manner, then tracking their history with your app / business.
SOCIAL LOGIN PACKAGES
These are often cheap and nasty solutions that add complexity to your apps as you are finding.- especially when you need to look things up by user.
OPTION 1 - COMPLEX APPS
Your API could look at the token issuer (ISS claim in the token) and download token signing keys from either Facebook or Google - if JWKS endpoints exist. Then create a user from the access token's sub claim if required.
OPTION 2 - SIMPLER APPS
Deal with only a single type of token in your UIs and APIs, which will work like this. It moves the complexity to your Authorization Server (AS):
You have an Authorization Server (use Google maybe) to deal with token issuing and other central OAuth concerns
You have multiple Identity Providers (eg Facebook + Google) to support different login methods for users
During login Facebook posts a token to the AS
Then the AS issues its own token to your UI
The AS may be able to use Account Linking to provide a consistent user id regardless of login method
There is a learning curve in getting this working, but once done it can easily be scaled to many apps with zero code changes.
The proper answer is Auth0... see the below sequence diagram!
We are developing a hybrid mobile app (code is written in HTML and runs on browser shell as a native app on the device). We need to authenticate the user against an external security manager. I've seen the Gmail App in iPhone which opens a browser to authenticate the user. We are also looking to do something of that sort. We just need to gather your thoughts on how authentication can be done with some external security manager in a mobile app.
Also I noticed that Dailymotion website was able to know if the user is authenticated with Facebook. This looks like a cross domain authentication.
Can you please share your thoughts on how Google and others have implemented it?
What you are looking for is OAuth and OpenID services to federate your login. Depending on the architecture of your system you can implement whichever one you like or even a hybrid of both.
Take a look at this link: Federated Login for Google Accounts
It provides all the useful information you need.
Hmm this question seems old but in case you haven't found an answer here's how I did it with my hybrid apps :
open url on client side with the provider's (facebook/twitter/instagram) url for login
the user logs in and is redirected to the server's callback url (my server is written in nodejs)
once I've got the access token from the provider. I save this token and then create a token for the client to reuse every time the user wants to access a protected ressource.
Download the apk and test it.
If this is what you're looking for you can checkout both the client side code at : https://github.com/malikov/Authenticate.me-client-cordova-ionic
And the server side code at : https://github.com/malikov/Authenticate.me-Node-Server
Cheers
I am developing a desktop application that will interface with FB. FB insists that you provide a Site URL. Since this is a desktop application this doesn't really make sense. I set the site url to 'localhost'.
I just get the following error when I put 'localhost' in the url string
API Error Code: 191 API Error Description: The specified URL is not
owned by the application Error Message: redirect_uri isn't an absolute
URI. Check RFC 3986.
This looks like a pretty common error but I don't see any examples of how desktop applications should handle this site url requirement.
Can someone help me out?
Thanks
Pays to read the documentation to the end :)
Our OAuth 2.0 implementation does not include explicit desktop app
support. However, if your desktop app can embed a web browser (most
desktop frameworks such as .NET, AIR and Cocoa support embedding
browsers), you can use the client-side flow with one modification: a
specific redirect_uri. Rather than requiring desktop apps to host a
web server and populate the Site URL in the Developer App, we provide
a specific URL you can use with desktop apps:
https://www.facebook.com/connect/login_success.html.
I'm looking to implement Single Sign On for a native iOS app whereby logging in with this single sign on gives the mobile device authenticated access to our private service in a fashion that is somewhat similar to oauth.
The marketing text on openid.net suggests that "OpenID is a safe, faster, and easier way to log in to web sites.". Emphasis on web sites.
So the question is: Is it reasonable to implement openID on a native mobile app, or is openID only for web sites.
I've been scouring the web and I'm not finding a way to fit openID in as my login option.
The best way to do this seems to be to use a UIWebView and render a log in page from your site in it. Once the user logs in, they'll be redirected back to your site and have an auth cookie, which you can extract, store, and send on subsequent HTTP requests to the server.
See this, which has a sample code link at the bottom.
OpenID sends its messages as a series of HTTP requests and responses. Your app and the openid provider must communicate to each other via HTTP post, and you will need to redirect the user to corresponding URLs, and have a URL for the user to be redirected back to. As such, you will probably find it difficult to integrate with your app.
Derek Knight claims to have been experimenting with iOS and OpenID using the Janrain Engage iOS SDK. Although the github link he references no longer exists and he doesnt provide a complete and verified solution, he does offer an idea for how it might work.
OpenID and iOS development - gordonknight.co.uk
Janrain Engage for your iPad Apps
The accepted answer diminish the OpenID protocol. OpenID is a federated authentication protocol aiming simple SSO experience, its a web based protocol but it can be implemented if you design an authentication broker.
APPs share nothing, apps should never access anything but identity token and access token (if allow). here is a link to get you starter in the right path to build seems-less SSO in the mobile between apps regardless the app isolation level.
https://www.pingidentity.com/developer/en/resources/napps-native-app-sso.html
Libraries:
https://github.com/openid/AppAuth-iOS
https://github.com/openid/AppAuth-Android
When I develop a App Project on iPhone, it's need to authenticate.
My basic requirement is to have custom login screen. But the Service providers currently provide OAuth protocal only, not XAuth protocal. Does this mean that if I use OAuth protocol, it will can not be achieved what I need (custom login screen), and I must be loaded the service provider's interface by UIWebView to enter user name and password?
Best Regards!
For OAuth v1, yes that is the only option.
For OAuth v2 there are more "flows" which can be used. See this article for a intro to OAuth v2.
So it all depends on who you are connecting to as to what version of OAuth they support. You may like to connect whoever you are connecting to to see if they provide other options. I know people that are working with a vendor so that the vendor are supporting some of the OAuth v2 extendations for them to make it nicer for there mobile applications as the "web" view looks shit on mobile devices.
On the other side, once you have the token it's yours until revoked. This means you can save it and use it from then onwards. This means you may only have to display the login only when the token fails.