I have an oauth app so users can authenticate their youtube account. I would like to be able to insert live chat messages on their behalf. I have attempted to submit live chat messages to the API using the authentication tokens for the users but it still shows the author of the message as my app. Is there a way to insert live chat messages on behalf of oauth authenticated users?
https://developers.google.com/youtube/v3/live/docs/liveChatMessages/insert
Note: I am posting this question here based on the instructions for youtube live api support found here https://developers.google.com/youtube/v3/live/support
After stepping away from this problem for a bit and returning to it I came to find that the API does post chat messages on behalf of the user when using their oauth tokens. My problem was in my application. I was not including access_type=offline in the url when authenticating the user. Without this parameter there is no refresh_token retrieved. My application logic was falling back to default tokens when the refresh token was not retrieved.
Related
We have a mobile application and end users are authenticated via Firebase.
Current behaviour
While onboarding users, we register every user on Firebase with an email and a mobile phone.
Once the user is created on Firebase we the use the link generation API generateSignInWithEmailLink and send an email to the users.
Users click on the email from their mobile phone and it automatically launches the App.
Desired behaviour
Instead of sending an authentication link in the email, we would like to use the SMS token validation feature of Firebase
This is very easily down via a browser based application.
How do we implement such a feature that on Android/Ios?
Option
We provide a custom backend HTTP end point which gets called by the user
From this backend, we instruct the Firebase Admin SDK to send a new SMS authentication token to the have any endpoint which allows the back end to send a SMS authentication token to the end user's mobile.
Is this possible? At first glance, I could not find anything in the documentation.
Thanks
https://firebase.google.com/docs/reference/admin/node/admin.auth.Auth
Firebase does not provide a generalized service for verification via SMS. You will have to find another service for that.
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.
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 don't quite understand the api flow for twitter on a per-user basis for API transactions.
Here's my understanding of the user transaction flow:
1./ User signs into our web application.
2./ User authenticates with twitter and then the API sends the user back to a callback destination with a provided oauth_token and oauth_token_secret.
3./ We store the oauth information into a database.
4./ Now we have there access tokens and can send tweets on their behalf without needing them to log into the application again.
HOWEVER, this is not working correctly. When I try to supply the oauth token information, i'm getting invalid or expired token. OK so instead i supply the oauth token provided to me with the user oauth tokens given by the owner of the app and it works.
I think I'm mishandling the authentication process.
I'm reading here at the authentication docs.
Can anyone help me understand how i get my app to handle status updates on a per user level?
Thanks.
Ok. However I read for twitter there is no expiration
This is the actual transaction flow your application will take in order to use Twitter:
Register your application to Twitter to obtain an OAuth consumer_key and consumer_secret. This is for Twitter to identify the application that your user will authorize to access it's account.
When the user wishes to Tweet or access their Twitter resources through your app, The OAuth handshake process will redirect to Twitter, with the application's consumer_key so that the user will authenticate on Twitter directly. Once user authentication is successful, Twitter will provide your application with an access_token.
That's essentially what happens, except that Twitter uses OAuth 1 protocol so the handshake is more lengthier.
Access Tokens do expire for security reasons. It's like when you login to a system, the session is active for a period. When they do expire, you will have to request for an access token again.
I don't know if that explains your question.
I have developed a simple API to allow communication between my Android/iPhone apps and my server. In my application, users need to authenticate themselves and they do it using login/password credentials with the following API call:
http://api.myapp.com/login?user=xxx&pass=pass
Application receives in return:
{ "api_token": "xxxx-xxxx-xxxx-xxxx" }
So basically I exchange my credentials against api_token.
I would like to add Facebook connect support. I have successfully used the Facebook SDK and receives the correct access_token.
However, I need to implement a mechanism to exchange access_token with api_token
Assuming the user has already connected his account with Facebook (on his web user panel), what would be the best implementation to proceed to the exchange?
Here is how I finally did it. It's working very well for more than one year, never had any problem. The idea is to exchange tokens using the following API call:
http://api.myapp.com/login/facebook?access_token=<facebook_access_token>
Server side, you verify validity of the access_token with a simple
wget -qO- https://graph.facebook.com/me?access_token=<facebook_access_token>
Which sends you back a JSON with all user information, including user's Facebook ID. Assuming the user has already connected his account to Facebook, you can lookup the user_id and send back an api_token.
http://developers.facebook.com/docs/authentication/
The best implementation will naturally depend upon your current platform. There are several Ruby on Rails gems, for example, that handle to whole Open Authentication bit for you.