Browsing though the Foursquare API documentation, I noticed that when obtaining an access token with ajax there is no need for a secret key (for obvious reasons). But this makes me wonder what is even the point of having to register apps with foursquare in the first place if you can just fake being any app by using their client key. Why do they allow this?
https://developer.foursquare.com/docs/oauth.html
Your answer is in the document you referred to
Since each credential is tied to a particular URL
The point is Foursquare is looking at the URL of the requesting script for security. If there is no registration there is no URL to tie the credentials to.
Related
Is there a way to automatically authenticate the google javascript api client, without user interaction?
Something like this:
User loads webpage -> webpage automatically signs in into a predefined user account -> api calls get executed
Basically i want to prevent the popup where you have to select an account and sign in to it. As the account which will be signed in is always the same.
EDIT:
pinoyyid answer looks promising and is what im looking for. But this only works if the user has signed in with an account at least once, if im not mistaken.
Now i dont want to use an account supplied by the user, but a predefined account which i am the owner of and sign this account in.
Im not entirely sure if this is even possible, as i have to provide the password/some authentication code to google and somehow do this in a secure way.
Use Case: The website will create a Youtube Broadcast via the Youtube Data/Livestream API for the specified account.
Yes you can do that. Referring to https://developers.google.com/identity/protocols/oauth2/javascript-implicit-flow
there are three pieces of information that will get you where you want to be:-
The OAuth URL can include a login_hint which is the email of your intended user
The OAuth URL can also include prompt=none which will do its work silently
This all needs to run in an iframe because this is based on origins and redirects.
==EDIT==
If the requirement is for a browser client to connect to a Google Account other than that of the browser user, then this is not possible. It's kinda obvious really that to do so would require a credential in the browser which by definition is not a secure environment.
The approach I would take would be to use a service such as Lambda or Google Cloud Functions (or whatever marketing name they have this week) to create a proxy for the corresponding Google API using a credential stored server-side.
I have successfully implemented Google Login in my web application, using OAuth 2.0 for Client-side Web Applications. For most needs, I just need to have the user log into my application once, and I pass the id_token back to my server to authenticate it, and give back a JWT token to the front end on success. The user doesn't have to log every time they visit the page by storing that JWT token in the browser.
Now I want to build some additional capabilities into my application that require me to act on behalf of the user, and so I have to incrementally ask for additional scopes. I think I have a handle on that aspect.
On the client side, I gain consent to use a Google API on behalf of a user, and then use the Bearer token I get back to make a request to that API, then I get back an object from Google.
Now I want to convey that object to my server (my back-end) to store some information in my database associated with the user that is logged into my system. How do I authenticate, on my server, that the object I got back from Google, by proxy through the browser, actually belongs to the user who is conveying it to my server.
What's to stop someone from using cURL with their valid JWT token to my server and conveying some arbitrarily constructed Google object of their own creation. I don't see anything in the Google response object that I can verify its authenticity on my server (like I can with the id_token I get from their successful login, as described here). Perhaps there is a 'sub' field (which I think is Google's notion of identity) on the object which at least lets me know it belongs to the Google User, if I can trust the object's authenticity in the first place.
Can anyone set me straight and give me a reasonably intuitive mental model to organize my thoughts around, and tell me if I'm way off base with my concerns here, or if I'm approaching this from an entirely wrong vantage point?
My IdentityServer application is configured to use Google login. I am using OIDC. This question is about external claims.
At login time, my application has access to all of the claims Google sends back from the auth request. I can access them in my custom implementation of UserServiceBase in the method AuthenticateExternalAsync (via the context). I can even add them to the AuthenticateResult object so when GetProfileDataAsync gets executed after the user has accepted the consent, I can access them via the ProfileDataRequestContext.Subject.Claims list. But this is the last point they will be in memory.
If I do not save these claims in a database, how can I access them once the login process is over? I want to keep my id_token simple so I do not put claims (other than sub) in the token. So I need to call the /userinfo end point to get the claims, but by this point they are no longer in memory.
What is the cleanest way of getting these claims back? To be clear, I want to get the claims from Google when the user calls /userinfo and translate them to the claims naming convention of my application. (I do not want to store them in the id_token at login time if possible... as per OIDC spec)
Note: This question is similar to mine, but that does not address how to do it using IdentityServer3.
Yes, you will need some persistence mechanism for the claims from the external provider. You should already have this, as the subject claim that you are issuing from IdentityServer should be unique to your token service (and not the unique id google gives you).
I'm writing a web application that reads my personal calendar data, crunches stats, and then spits them out for the world to see. I don't need an authorization flow. Is it possible to leverage the Google APIs without going through a user sign-in flow? In other words, I want my personal Google account permanently and securely signed in to my server without the risk of my token invalidating or having to re-auth.
Right now I'm signing myself in with an offline token, then uploading the authorization file onto my server, basically spoofing the server that I already auth'd. Is there not a cleaner way?
I've spent hours reading through the API docs and Auth docs, but haven't found and answer. If there is a page I've missed, please point me to it!
PS. I'm using the Calendars API through Python/Flask on Heroku, but that shouldn't matter.
An alternative approach is using a service account while sharing your calendar with that service account. See https://developers.google.com/accounts/docs/OAuth2ServiceAccount
So, you want to be remembered.
If you want to dispose of any kind of authenticacion but yet the user needs to be recognized you should be using a cookie.
On the server side that cookie should be used to select the offline token.
Of course, without that cookie the user needs to be authenticated in any way. I would make them reauth by Google so you get a new offline token.
Hope that it helps.
I would like to access my own facebook news feeds using spring social facebook. I have registered my app and i could able to get app key and secret key. How to generate facebook access token for given app key and secret key using spring social facebook(programmatically)?
Now i'm using the link https://developers.facebook.com/tools/explorer generate the temporary access token which is valid only for 60 minutes.
How to generate the access token in my java application itself without having any login page redirecting to facebook redirecting back, etc.
If you're wanting to use the token to access user-owned resources at Facebook (e.g., the user's timeline, friends, etc) there's no way to get a token without involving the user. That's on purpose so that you aren't allowed to fetch data or write data to Facebook without getting the user's permission to do so.
But if that's what you want, then you must redirect the user to Facebook and back. This is OAuth 2's authorization code grant. Spring Social's ConnectController can help you with this.
You might be able to do it via the JS API, but it's been awhile since I've done it that way and I know a few things have changed at Facebook in that regard. And it probably relies on OAuth 2 Implicit Grant (which involves a redirect).
There is another way to obtain an access token without redirecting: Via OAuth 2's client credentials grant. But I don't think that's what you want. Such a token can only be used to work with non-user resources (such as Facebook's Insights API). But if that's what you want, then you can use OAuth2Template's authenticateClient() method.
Again, to be perfectly clear, it is very much by design that you can't obtain a user access token without involving the user. And with Facebook, that will require redirects.