I am building a custom photo gallery for my site which uses Flickr as the backend. I feel like I need to authenticate with Flickr using the new Oauth system.
Everytime I look into using Oauth with Flickr it all shows how to do it to "provide in your applications a secure way for people to sign-in into their Flickr accounts"
I don't need anyone else to be able to sign into my site. I just need it signed in to MY Flickr account all the time. All the functionality that links to flickr is behind my own authentication system anyway.
Does anyone have any ideas how I can go about having it signed into MY account all the time and none of this sign into user accounts sort of stuff.
Thanks.
Having it signed into your account all the time is risky because others could look at the source code for your site and extract your username and password.
Instead of using OAuth, why don't you utilize the authentication key that Flickr provides when you sign up for an account?
You need an OAuth access token for most request involving photos that are not public. So unless the gallery you're building only accesses public photos, you'll need an OAuth access token.
Having said that, there are lots of 3rd party libraries (list on the api page) to handle most of the OAuth authentication and signing of each request. Once you've obtain an access token, you can persists locally in your database - it doesn't expire, but it can be revoked. Once you have the access token, you need it to sign most of the request you make to the api.
For example even to search your own photos - if they are private - requires an access token and a signed request.
Related
I am building an ASP.NET Core 6 Web API application for mobile clients (and maybe later SPA JS app). The application should have sign-in with Google option. I also want to add my own app's custom sign up and sign in options that would also be based on JWT authentication and not cookie.
I understand that for my custom sign in flow my app will generated JWT that will be sent to the client.
But I have few questions how that works when user signs-in with its Google account:
who's responsibility is to generate the JWT when user signs-in with its Google account? Is that responsibility of Google or mine application? I don't want Google to return JWT to the client in the cookie.
Then when client is authenticated with Google, and sends requests to my application, how can my application validate JWT token it gets?
When user signs in with Google for the first time, should I automatically register that user in my application (I am using Identity framework) by taking claim values (email) from the JWT? What is the general practice here?
I am trying to understand these processes and flows so sample code is not necessary (but I do welcome it).
Ad.1. Normally, in a larger system, you would have an authorization server (AS) that would handle user authentication and the issuance of tokens. Your clients would contact only the AS, and the AS will be able to provide the user with different forms of authentication: e.g., through your website's password or through Google. The AS is the single point of issuing tokens to your clients. It can issue tokens regardless of the authentication method used. So it then doesn't matter whether the user authenticated with Google or a password, the client will still get the same access token.
Ad.2. When the AS issues token to your client, then you don't have any problems validating that token. The client doesn't care if the user authenticated with Google or not, it's not relevant in this case.
If you decide to skip using an AS and let the client receive tokens directly from Google, then you can still verify them. An ID token is a JWT and can be easily validated with a JWT library using verification keys provided by Google. Access tokens returned by Google are opaque tokens (If I remember correctly), and you need to check whether Google exposes an endpoint to verify them.
Ad.3. That is the general practice. When the user authenticates with Google and you notice that you don't have that user's data in your system, then you take the information from Google's ID token and create a user entry in your system.
I get it that Oauth is used to grant permission to a third party application to access a user's data (like photos on his facebook account) without revelaing his facebook credentials to the third party application. For example, when you try to use an online photo editing tool and you want to load a photo from facebook, facebook will pop up a message asking whether you really want to allow the application to access your data. So at that point facebook just returns a temporary access token and the app can use it to access your facebook photos. (as i understand the scope for this access token is such that it only has permission to access the particular user's photos only) Yes, this sort of a setup is required because you can't trust a third party application that much as to give away your credentials.
Assume somehow instead of oauth, facebook used api key authentication. This would mean that all third party applications that have subscribed for facebook API already have a key which they can use to access facebook's data sources.So that the app can directly take you to your facebook photos and facebook will not notify you that an outsider is trying to access your private data. This approach is not suitable for an api that exposes user sensitive data but for apis that expose not so user specific (like google maps) data, the api key approach should be enough, right ?
So my question is, what are the criterion to decide which authentication type should be used ? And appreciate feedback if my understanding is wrong.
Here are 2 of the standard 4 Oauth2 flows which cater for the scenarios you mention.
Authorisation Code
Client Credentials.
Using your Facebook example above you could think of like this:
Use Authorisation Code flow for your "Oauth" scenario, where your app needs delegated authorisation to access a user's Facebook photos. This means the user must login and grant access to your app and your app must have an API key (client ID) issued by Facebook.
Use the client credentials flow for your "API Key" scenario. This would be when your app needs access to, for example, public Facebook pages / info and thus does not require specific user consent and can just use its API Key (Client Id & Client Secret)
I have a question more related to the way OAuth 2 is working but since using IdentityServer to implement OAuth I think it's relevant. I could not find an answer anywhere.
I'm building a website and a mobile app that consumes my own API. Each user of my app will have a username and password, that will give him access to the app/website and though the API to his information.
I'm not sure about the right way to handle the flow for user login:
On the website I have my own designed login form. I don't want to move the user to my auth server to login, and then have him approve the information he gives - he is the user on my system - I have access to all information - kida like facebook has a login and access to the informatio - they don't ask what you're willing to give them. So is implicit really the way for this?
On the mobile app I also have a login form and now I read here (https://datatracker.ietf.org/doc/html/draft-ietf-oauth-native-apps-10) that the OAuth approach is to have the login in a WebView?? Doesn't look like facebook login is in a WebView on their mobile app.
The approach I was first lookin at is the Resource Owner. Users will login, get the token and the refresh token and can start working against my APIs. But storing my client_id and secret on the mobile app? on the website javascript files? doesn't feel right. I can of course make a call to an API that will mask those and be a proxy to the login process... but... (read #4).
In the future I would like to allow access for third-party developers. For them to allow login for users of my system I will use the implicit flow. Also, I plan for those developer accounts to have restricted API access (for example, the number of calls to the API will be limited by plan). What prevents those developers from asking for the username and password of their account on my system on their website, getting the response from my servers with the access token and refresh token, and using my API however they want, without restrictions, and having access to the entire user profile?
Lets say I'm sticking to the resource owner flow, receiving back from the server a token and a refresh token. What should I store on the mobile device and how? What should be stored in the browser and how? the refresh token? and each time he opens the app get a new updated token with that refresh token?
Edit
Just to clarify, because I find a lot of lectures and articles that explain the process from an API consumer point of view (ie. the third-party developer): I am the API owner and the auth server owner, I'm the owner of the user accounts (they are my users of my services), I'm also my own consumer (though the website and the mobile app), and in the future I want to enable third-party developers to allow my users to login with their accounts of my service (kinda like Facebook or Google)
You're correct that you shouldn't store the client_secret in your app, but I doubt you will get around storing the client_id. You could disable the consent screen for your app as well, and build a native login view. You need to store the access_token and the refresh_token on the device (maybe encrypted in a database) if you don't want the user to login everytime they use your app.
As for problem 4, you could do the following:
Embed the client_secret in your (web) app
Set up which hosts have access to your api on the IdentityServer
The IdentityServer generates a salt and sends it to the client
The client calculates a session_secret using hash(ip_address + session_salt)
The client uses the session_secret and the client_secret for the API call
Server validates the hash and client_secret
It's nearly impossible to completely prevent someone from using your API. But you should add various rate limiting methods, such as limiting IP addresses, API calls etc. But nothing will stop someone decompiling your app and accessing your client_id.
I have an application that needs to display number of followers and following (users/show.json) for a random user on a public page (authentication is not required).
With the Twitter API 1.0 it was quite easy as authentication is not needed for the request. With the new Twitter API 1.1 is no more possible, so I need to authenticate the request (via OAuth).
Is it possible only "authenticate" the application and not the user too?
I mean: can I avoid to ask user to login and only authenticate with application key/secret? Or everytime I need to create a token with user credentials too, creating callback, etc.?
Yes, it is possible! If your application doesn't need to do things like post statuses or send direct messages on behalf of a user, you should be able to retrieve all of a user's public information with a single hardcoded set of Twitter OAuth credentials, and not require the user to authenticate.
Login to Twitter and go to the developer dashboard at https://dev.twitter.com/apps
Register a new application; after the application is registered, view the application details. You'll see an "OAuth Tool" tab, where you'll find all the relevant OAuth values for that application: Consumer Key, Consumer Secret, Access Token, and Access Token Secret.
Using these credentials, you'll be able to make requests to the new Twitter API.
If you're not comfortable using the Twitter API directly, there are a number of good API wrappers out there for various languages -- among others, the Temboo SDK, which will give you code snippets for calling various methods (and also gives you a place to securely store your Twitter credentials, so you don't need to bake them into your application).
Take a look at:
UserTimeline
GetFollowersByID
(Full disclosure: I work at Temboo.)
The easiest way to do what you're asking is to use Twitter API 1.1's 'application-only authentication' feature, which works for much of the API. See Application-only authentication. You can see a Python example of it in get_bearer_token.py.
Once you have a bearer token, you only need to include that in your request authorization header - signing is not necessary.
I'm working on a mobile application, in which, the user can go for Facebook, Twitter or Foursquare authorization (via OAuth) rather than creating a new account and password.
The problem is, I'm not sure what should I store in my DB to point a 3rd party account. The auth_token, acquired from OAuth process seems to expire or change in some situations (like when the user changes password). So, it's not a good option.
What would be the long term option? I mean, even if user unauthorized my app, then authorizes it back, I would like to be able to find out the local user corresponding to them. Should I use the respective API's of each website and dig out user_id and store it? That would be consistent in between sessions I believe.
Any suggestions?
Thanks.
When you are getting the authorization from the sites, you need to only store the access_token (and refresh token if OAuth 2.0). With a OAuth 2.0 access_token, it will expire occasionally and you will need to use the refresh_token to get a new access_token. The user changing the password will not change the token, but the user would have the ability to revoke the token at any time.
Since they have to go through your mobile app to get the OAuth authentication, you should be able to link them together easily.