Hello I'm very new to the app side of things.
I need to know (as it state from the 1st of OCT) that you need a secure URL for page apps. Does that mean you must have SSL running https:// or you can just use http://?
Yes, I believe you have to get a SSL Certificate for your App Page.
From the Facebook Developer Blog - Keeping Users Safe:
As an app developer, you can help us by:
Acquiring an SSL Certificate. Contrary to some feedback we’ve heard,
acquiring an SSL certificate is relatively inexpensive, and the
ongoing cost of supporting SSL for most apps is low. The sooner your
app supports HTTPS the more secure our platform will become. All Apps
on Facebook (Canvas and Page Tabs) must support HTTPS by October 1.
Reviewing the Authentication guide and implement OAuth. This updated
authentication guide walks you through the OAuth 2.0 flow and how to
implement OAuth with CSRF protection. Our new OAuth flows provide a
more secure and reliable way to obtain access_tokens than our legacy
authentication flows. All apps must support the new OAuth flows by
September 1.
Here's their Authentication Guide (also linked in their blog post).
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!
I have been reading the developer blog on Facebook this morning and stumbled across this article saying that all Canvas pages are to use OAuth and SSL.
• an SSL Certificate is required for all Canvas and Page Tab apps (not
in Sandbox mode)
• old, previous versions of our SDKs will stop working, including the
old JavaScript SDK, old iOS SDK
Does this really mean that any application that has been created before this date will stop working? Am I really going to have to buy an SSL certificate for each application?
Yes looks like it. They told developers on 11th May 2011 :
Today, we are announcing an update to our Developer Roadmap that
outlines a plan requiring all sites and apps to migrate to OAuth 2.0,
process the signed_request parameter, and obtain an SSL certificate by
October 1.
Migration to OAuth 2.0 + HTTPS timeline:
July 1: Updates to the PHP and JS SDKs available that use OAuth 2.0
and have new cookie format (without access token). September 1: All
apps must migrate to OAuth 2.0 and expect an encrypted access token.
October 1: All Canvas apps must process signed_request (fb_sig will be
removed) and obtain an SSL certificate (unless you are in Sandbox
mode). This will ensure that users browsing Facebook over HTTPS will
have a great experience over a secure connection. We believe these
changes create better and more secure experiences for users of your
app. A migration plan below outlines the potential impact on your
apps.
From here:
Please Note: An SSL certificate is not required for user
authentication on your site, Likes, Comments or other things. It's
only used if you want to show your site (or parts of it) inside the
Facebook.com domain.
Once your SSL certificate is installed on your site, you'll simply
need to enter your new secure URL into the "Secure Canvas URL" and
"Secure Tab URL". To obtain and install an SSL Certificate, we've
partnered with The SSL Store in order to make the process as smooth as
possible. SSL Certificates that work with Facebook can be purchased
for as little as $11/year (multi-year) or $18 for just one year.
Purchasing a certificate through The SSL Store takes about 10 minutes
and they have a 30-day money back guarantee.
Below are instructions on how to purchase a new SSL certificate for
your site so that you can use the Facebook Page features without any
issue.
It does seem that you need to have one, and not one per app.
I was wondering what this information means exactly:
October 1: All Canvas apps must process signed_request (fb_sig will be removed) and obtain an SSL certificate (unless you are in Sandbox mode).
Does anybody have more detailed information on what will happen on the 1st october and the tutorial about how we should switch to secure page tab URL? Will all the applications be unaccessible if we don't do this?
Thank you!
facebook will not allow to add a new app that doesn't have a secure tab url (https)
if facebook will remove all old apps that do not have a secure tab url is not known at the moment.
a tutorial is not needed, the only thing you have to do is to provide https to your apps,
in the apps settings.
there are a lot of free ssl certificate providers out there - or maybe your host provides ssl to your webspace.
http://tinyurl.com/3oqxutj
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.