I am making a widget for my iPhone to fetch data about my Instagram followers. I won't be putting it on the App Store, and I won't be fetching any other users' data.
Can I do this? I have tried to figure out what to do but I think I have to register my website, even though I'm not making a website and this won't be shared with anyone else.
As stated in Instagram Developer Documentation, you will have to register your application before using the API.
1. Register
We'll assign an OAuth client_id and client_secret for each of your
applications.
2. Authenticate
Ask users to authenticate and authorize your application with
Instagram.
3. Start making requests!
Make requests to our API Endpoints with the users' OAuth credentials.
The takeaway here is that you'll need the OAuth credentials to access the API.
Related
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 am building a REST API.
For registering a user, he needs to authenticate on Twitter.
Normally, I would use an Authorization code provided by an OAuth2 server but it seems like Twitter does not implement this type of authorization.
I don't want my mobile app to send the Twitter token to the API to register the user. I see this as a security flaw.
I checked OAuth echo (https://dev.twitter.com/oauth/echo) which seems okay. The user passes the credentials to my API, and my API checks the user against the twitter API. Twitter then returns a user object. It does not return a access token though.
Is it the only way to do this?
Thanks for your help.
Yes you are correct. Using OAuth Echo will use you as the third party for that individual without exposing your Access token/key and Credentials.
Just be aware that you're under a different rate limit from Twitter's API when you're going through that route. In some cases it's an increase in limit while it's a decrease in other.
I need to access the YouTube API, authenticating as a single account so I can access its videos, tags, comments, etc.
A Public API Access key does not seem to cover this scenario as tags aren't visible to the public. Is it necessary to implement OAuth just to authenticate one account? I have no intention of having other users authenticate with the web app - only the YouTube account that belongs to the owner of the web app.
I have the username & password for the YouTube account. Is there no way to authenticate one YouTube account with the API as a single-user?
A Service Account seems most suitable for me, but apparently the v3 API doesn't support them.
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.
Which URL I should user for authentication user in the Twitter?
For example, in the Instagram token for user can be received when user click on the following link
https://api.instagram.com/oauth/authorize/?client_id=XXX&redirect_uri=XXX&response_type=XXX
After this its return token and I can work with user profile.
How to build such link for twitter?
Twitter API has several ways to authorize and it depends on what you want to do for determining which approach to take.
The OAuth2 approach that instagram takes is called application-only in Twitter API. The thing about application-only is that you can only use it on endpoints that aren't associated with a user. e.g. it's great for search, but doesn't work well for tweeting (which is something a user would do).
A couple other approaches are Single User Authorization, which is good if your app only needs one set of credentials. e.g. a server app. Another is Pin Authorization which is a work-around for devices that can't manage Web callbacks. These use OAuth 1.0A.
There are a few other OAuth options, but this was just to give you an idea about the available choices and the need to think about what you want to accomplish and match that with what the Twitter API offers. Here's the Twitter docs for more info:
Authentication and Authorization