I develop an ASP.NET website. It will contain text articles and some of them will contain pictures from my facebook account above and beyond the text. Note that I'm going to use only the public albums from my account.
So I created a sql table and binded the articles, the albums and the photos (in fact the IDs of all of them). I already used facebook api sdk and it was a great library.
Obviously any visitor of my website (even he doesn't have a facebook account) mignt be able to see the articles and the pictures withount visiting facebook and without authentication via facebook oAuth to access them.
Well here are the questions:
1) How do I get the photos a public album contains by album id and user id without authentication? (I don't know, maybe I should use the other parameters than album id and user id)
2) How do I get the properties (name, id, etc) of a public album?
With out an access token there's very little you can get from the graph api.
Just try yourself by directing your browser to: http://graph.facebook.com/YOU_USER_ID.
You can also check the fields/connections tables in the User object documentation, where it says "No access_token required" in the Permissions column (3rd) you can get with out a token.
If you want to get other data of yourself and serve it publicly on your site you have two options:
Use the server-side authentication flow, get a long lived access token (60 days), save that and use it for the following 60 days to get your data from facebook.
Then, when it gets expired go through the authentication process again.
It will just be you who needs to go through it, not your users, and only once every 60 days.
Log in yourself, authenticate against your app, get all the data and persist it on your db, then just present that to your users.
You'll need to update things every once in a while.
Edit
The server side authentication flow guide has an example written in php.
It's a simple example which does not cover all scenarios but it's a good start.
I have implemented this in python and java but it's not something that can easily be shared since it spans across multiple requests and states, and so I'll just describe the flow I think that you should use:
Inside facebook you go to your canvas app
Facebook will make a POST into an iframe with your canvas url
In the post data you will get a signed request, decode it and check if it has an access token, if so check when it expires. If all is good save that token and the auth process is over, otherwise:
Redirect the user to the oAuth dialog along with your redirect url and permissions that you require.
After you allow your own app you will be redirected to your "recirect_uri" with the code parameter (in the querystring).
Exchange the code for an access token against the facebook servers and save the token.
You can then redirect yourself to the canvas app or just stop there.
That should do it for a long lived access token which you can then use for 60 days.
As for persisting your fb data on your own db, it's a pretty trivial operation to save data on a db, and it all depends on what data you want to save, how you need to encode/use it (json, xml, plain text).
For example, let's say you want the display your own photos, then after you get the token (as described above) just query from your server for your photos by issues an http request to: https://graph.facebook.com/me/photos?access_token=XXXXXX.
You should get a json encoded result, iterate over that and save each picture as a record on your db.
To retrieve list of user's albums you need to issue next GET request to Graph API:
https://graph.facebook.com/me/albums?access_token=...
And to retrieve list of photos:
https://graph.facebook.com/ALBUM_ID?access_token=...
But you cannot read user's albums (and photos) without authentication and requesting user_photos permission.
According to album documentation:
To read an Album you need
Any valid access token if it is public and belongs to a Page
The user_photos permission if it belongs to a User
The friend_photos permission if it belongs to a User's friend
So generally you have only two options to achieve the result you want:
Use Facebook Page to store all the Albums/Photos you want to display on site
Read 'em using Application access_token.
This will allow you to completely bypass authentication flow at all.
Use your personal account to store Albums/Photos
Authorize application (client-side/server-side) and grant user_photos permissions
Extend access_token for your user and store it
Use your personal access_token to access your Albums/Photos
Related
TLDR; Can multiple different users be authenticated and retain authentication via a generated custom token IF that custom token for each of those users is being generated always by the same UID? That is, User1 gets custom token generated by UID1 (via createCustomToken(UID1)) and then signed-in with signInWithCustomToken(), THEN User2 gets and signs-in with custom token generated using UID1, then User3 same thing etc etc, can ALL these users happily remained logged-in and experience no interruptions despite these other users being authenticated in this identical manner?
Long Version:
Ok, so I am trying to create a link-sharing system wherein a user who navs to this link can access a specific subset of my project's Firebase resources.
I have already tried using Firebase's signInAnonymously() to do this, but I dont like the way that Firebase does this for a whole host of reasons I dont want to get into.
The way i want to accomplish this is by:
generating a unique link (really a Firestore unique doc ID with some access data stored in that doc)
having the unauthenticated user navigate to some landing page, calling the cloud function and passing that unique link (lets call it a UID now)
cloud function, upon recieving this UID, will createCustomToken(UID), returning the token back to calling user
and the user will authenticate themselves with signInWithCustomToken(returnedToken) and access provisioned resources
Now, that is all well and good, but my question is:
If two (or any amount more people) people navigate to that same link and therefore pass and create token with the same UID, will they all be ok to continue happily using Firebase resources? Or is it because they got tokens created for them which utilised the same UID a sort of token-conflict is made, and therefore any next user who authenticates in this manner will revoke the previous user's auth token.
I havent been able to try this, and it seems like every question asked about these custom tokens relates to the generation and expiry time of them, which I understand. I wish the Auth docs were more clear on the mechnics and pitfalls of using Custom Tokens. I also havent been able to try it myself as it would be quite alot of refactoring, and was hoping someone could give me a straight answer to this.
Yes, a user can login on multiple devices without affecting other sessions at the same time irrespective of which auth method you use.
I'm not sure what the unique links are but it's not a good idea to pass the UID itself around if you function just takes a UID and returns a custom token as UIDs are pretty short and just a random string. It might be best to add a custom signed JWT in the links that contain the UID in payload so you can verify them before creating Firebase Custom Tokens.
What I want
I have a list of people with all their personal information (name, first name, date of birth, email, etc.). I created an account for each of these people using their email/phone + a password I generated for them.
I want to send to each of these people an email/SMS with a link allowing them, once clicked :
to be directly connected on our website, without having to type a password or using a third party as Google/Facebook/etc.
and I want the link not to expire after the first use. The user must be able to click on it several times and be connected to our website each time.
What I tried
This is what I tried so far, unsuccessfully :
Passwordless Auth with email link: using both backend and frontend. Doesn't fit my needs because the signin link works only once by design.
Create a custom token with Firebase: as I understood, the token will expire 3600 seconds after creation, which is not useful for me.
Implement anonymous auth: it still need the user to type email+password at some point if you want to convert the anonymous account to a permanent account (because I don't want to use Google/Facebook/etc auth). Plus, it will need consequent changes in all my website code to work.
At this point I realized that Firebase doesn't have a solution that fits my needs. I started to fiddled around as best I could.
The idea
It works as the following:
First I create an account for the user in Firebase + a unique document in a collection in Firestore. That document contains 3 fields: magic_token, email, password.
Then, I create a link to our website with a unique token as a parameter in it. I store the token as magic_token in the document I described above. I send the link to the user.
The user clicks on the link, get redirected to my website. In the front, I detect the presence of the token in the parameters of the URL, I retrieve the document in Firestore with the corresponding token.
Using the email and password stored in this document I call: signInWithEmailAndPassword() to login the user.
PROS:
it fits my needs.
it is easy to implement
CONS:
the user password is visible in Firestore.
it's not very secure.
The question
Is there a proper way to implement a Magic Link that fit my needs? If not, how can I improve my own custom token authentication ?
I am currently building one web application, and I consider to use Firebase auth and its database. My concern is that if user id is on browser, does it make any security issue?
For example, say that my user id is 12345, and I would like to show some information about user 12345 on a certain page. In order to move to the certain page that I can see user's information, I click some element (like a button), and go to the page. (Ex: https://localhost:9876 => https://localhost:9876/12345) In this case, the user id is visible, but I am not sure if this is reliable approach.
Thanks.
EDIT: I just noticed that security rules should be used thanks to Eric's comment. However, I am not 100% sure if the rule can be used for auth object too. For example, auth object is used to get user id, but using user id, is it possible for someone to obtain the user's email address which is stored in auth object? For instance, in the above example, someone might obtain user 12345's email address using user id, 12345.
The correct way to secure user related resources is via a Firebase ID token. Database/Storage rules already rely on this mechanism. You cannot just rely on the correct user ID being provided. That provides no security. Instead, before return restricted resources, you should check verify the ID token and trust only its content which includes the UID. FYI: the Firebase Admin SDKs already provide an API to verify an ID token.
Typically the way to pass the ID token (if you are not using real-time database), is as follows:
Single page app: you can call getIdToken() and then pass the latest ID token in the URL query parameter, post body or the header as you send an XHR request to your server.
Traditional website: you have to set a session cookie. The easiest way is to set the ID token as session cookie and keep updating it on expiration. On your backend, you will verify this before returning the user specific resource.
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
I want to build a custom asp.net control to put on a webpage that will allow people to see a piece of information from my facebook account that requires auth. For the sake of simplicity let's just say I'd like it to display the last thing that I liked. I don't want the visitor to my site to have to be logged into facebook (nor would they have to be my friend on fb). I want my site to somehow store a token that I have authorized and then it will use this token for the access. I know this can be done initially, but I'm confused what happens when the token expires. Or for that matter if I log out from facebook. Is there some type of token or secret or something that I can request that can be auto-renewed again and again by my website independent of any login state that I have as an fb user? Does this require me creating an fb app and associating the token to it?
I don't have any code at this point, I'm looking for a higher level of guidance on the protocol that should be used here, from there I can hopefully figure out the code from existing samples, docs, etc. This is my first code interaction with facebook so don't assume that I know very much at this point :-)
EDIT: I've been reading everything I can about this topic and I can't seem to find a solution. In the past there was an RSS feed but that appears to be gone now. Then there was also the offline_access permission which is no longer available. This seems like such a simple task but I'm just not able to connect the dots. I have been able to get the initial user token with perms for reading "likes", that's easy. Now I can store that in my website's db and use it to make requests for that data anytime someone loads my page. But eventually the token will expire and I'm not seeing any automatic way to renew it that wouldn't potentially involve user "Larry", who happens to be browsing my website, being asked to supply MY facebook credentials. Basically it seems as though I could never log out from facebook or I'd be risking a broken feed on my website. Is the fb auth model just not set up to allow for thist? To summarize again - a user Bob wants to give his permission to acme.com to always be able to display Bob's most recent like regardless of whether Bob is logged in to fb or not. He would only want to have this stop working if he revoked authorization to the WhatDoesBobLike app which runs on acme.com. Possible?
-JT
You would need an extended access token. It will only last up to 60 days and from then you would need to re-extend.
If it were a page you could extend the user access token then grab the page access token which would never expire.
Read more at
http://developers.facebook.com/roadmap/offline-access-removal/