Twitter'll phase out HTTP basic authentication by August 2010. In the link my scenarios are from Desktop Applications. Basically my client should tweet new posts on a website.
This would be incredibly simple with HTTP basic auth, because I can store and use my account's username and password in the app to authenticate.
However, with OAUTH I can get final credentials by two means:
Callback method. You are redirected to Twitter, (login if isn't), click allow access, get redirection back to your callback URL.
PIN mode. You get a link to open, (login if isn't), click allow access, receive PIN code. Use this PIN code to authenticate your app.
Do I understand correctly that PIN codes also expire? How is it possible, given a username and password just to tweet from a client application? How can a server side script log in with the username/password and click allow access? All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
All scenarios I could google up are for a web application to authenticate via twitter where the user is in front of the browser to walk through the redirect.
The user has to be there to authorise you the first time (just as they'd have to provide you a username and password), but the resulting access token does not expire and can be reused (unless the user deauthorises your application, that is).
Store the access token - it's as good as a username/password. Better, actually - if they change their password, your access remains.
The PIN does expire under OAuth 1.0a. Using the verification code returned requires use of the temporary request token in the initial authorization request.
OAuth 2.0 defines more flows - one of which uses a direct login/password mechanism. It's up to Twitter to determine which flows they decide to implement. You can also embed a user-agent in the app.
Desktop apps suffered from a really bad user-experience with OAuth 1.0 which led to 2.0. It's doable, but painful. You can request XAuth access if you need to from Twitter as well. It's almost the same as basic auth.
Related
I am creating an application which aims at automatically creating Spotify Playlists in a central Spotify account (not the account of the end users).
I have set up this account and created the developer app for the secret and the client_id.
On the backend side, I am using PHP to authorize this central user, and it is working as long as I am logged in myself with that account.
Users that visit my website should be able to create playlists via that interface through the Spotify Web API without the need to authorize their account nor being logged in at all.
If I'm trying to open the same page on a separate device (without having any account logged in), it just gives me the following error:
User not registered in the Developer Dashboard
Is it somehow possible to perform this authorization process only on the backend side without the need for the user to authorize it?
Eventually, I want to send the playlist URL created in the central Spotify Account to the user who can open it in their own app or share with others, if they want to.
I try to avoid that multiple users must authorize for my app, since I don't need to access personal information from their account, anyways.
I used the 3-step process for authorization as described in this Stackoverflow Post: Spotify oauth2 with PHP curl. How to get authorization code?
If necessary, I will provide more information.
Do you have any idea, how I can implement this authorization process for the single account on the backend side, without the user even showing any authorization process of the Spotify Web API at all?
EDIT1: I am not trying to login on the behalf of my users, just automatically for my own account without the interactive login with Spotify. Is that even possible?
I received valuable feedback from the Spotify Developer Community that helped me finding a solution to the problem.
When you let the central Spotify account login to your app, you'll [get] an access_token (that will expire in 1 hour) and a refresh_token.
When the access_token of that account expires, let your server send a POST request to the Accounts service /api/token endpoint, but use the refresh_token in place of the access_token.
A new access_token will be returned.
A new refresh_token might be returned too. (I don't think that's even needed)
You can read more about it here.
I am building a web app for a booking platform and I am using oauth2 to use their API and authentificate users. My app is embedded in an other website named here 'X' that I am not in control. When the user click on my app, it loads https://localhost/?_account_id=12 in an iframe where _account_id=12 is its own account id in X website.
I am using the oauth2 authorization code flow so the user approves my app.
I am storing securely the refresh token provided by the authorization server.
I am storing in session the account_id parameter.
The authorization server doesn't support the famous prompt=none.
This is the first time I use oauth2 so maybe I didn't understand correctly how oauth2 works.
Since I can't only rely on the _account_id parameter because of security, I need to authentificate the user each time it connects to my app. Doing so, each time the session expires, the app prompted the user to approve my app.
With other apps available in X, I am never prompted to re-approve the apps. So when analysing them, the network developer tool of my browser lists this each time I connect to other apps :
204 https://other_app_provider/fr/admin?_account_id=12
302 https://other_app_provider/auth/?_account_id=12
302 https://authorization_server/oauth/authorize?_account_id=12&client_id={CLIENT_ID}&redirect_uri={REDIRECT_URI}&response_type=code&scope={SCOPES}&state={STATE}
302 https://other_app_provider/auth/bookingsync/callback?code={CODE}&state={STATE}
200 https://other_app_provider/admin
I repeat that there is no approval screen between the authorization and the callback.
My question : How to authentificate the user silently using the authorization code flow or the implicit flow ? In other terms, how to imitate the behavior described above ?
Thank you for answering !
Could I ask a few questions first - to see if I'm understanding the scenario:
Does the user login to the host app X first and your app then gets loaded as a plug-in?
Is this a federation scenario where different companies build the host and plug-in?
Do the host and plug-in use the same authorization server or are they different login systems with different user credentials.
Avoiding the consent prompt may be as simple as switching this setting off in the OAuth Client entry for your app in the Authorizatiom Server
It is worth being aware that OAuth logins in an iframe are often blocked due to clickjacking concerns and a more reliable option is to use a pop-up window for plug-in logins.
In some scenarios it can be very hard or impossible to achieve the desired behaviour of making the solution feel like a single integrated UI - but your requirement is becoming very common.
I've found the solution :
There was an option account_id in X authorization server not well documented :
Pre-Select The Account To Authorize
When calling your Admin URL, we pass the parameter _account_id. The value of this parameter can be used as the account_id parameter during the authorization process. Doing so will pre-select the account to authorize when using the Authorization Code Flow or Implicit Flow.
So I can imitate the behavior described in the question by passing account_id parameter in the authorization url.
Now, I understand the term Pre-Select by :
Check if the account owner is connected to the host app, select its account and silently authentificate the account owner in the app, if it's an already approved account.
If I didn't see it in the network developer tool, it was because they were provided by X, so maybe X use cookie/session to Pre-Select the account to authorize. I had to install third-party apps to see the account_id parameter in the authorization url.
Thank you for your answer !
I need to use Quickbooks online API to synchronize data between my system and my client's accounts on quickbooks.
I need to know if is it possible to complete the oauth2 authorization flow and make API calls without human interaction (without the need to interact with Intuit's authentication and authorization windows)?
I read the Intuit's docs on: https://developer.intuit.com/docs/0100_quickbooks_online/0100_essentials/000500_authentication_and_authorization/connect_from_within_your_app
On the first step, I made a GET request to:
https://appcenter.intuit.com/connect/oauth2?client_id=MY_ID&scope=com.intuit.quickbooks.accounting&redirect_uri=https%3A%2F%2FMY_NGROK_URL.ngrok.io%2FOAuth2PHPExample.php&response_type=code&state=RandomState#/Authorize/COMPANY_ID
Then, the Intuit's authentication and authorization windows opens and I need to put my username and password and then, click in the authorize button to get the authorization code.
Is there a way to obtain the authorization code without authenticate and authorize?
I need to automate this task to make API calls in the backend with PHP.
Thanks,
Marcelo.
Is there a way to obtain the authorization code without authenticate and authorize?
No... but read below.
I need to automate this task to make API calls in the backend with PHP.
You are misunderstanding how OAuth (either 1 or 2) works.
The very first time you connect you will be prompted to authenticate/authorize access to the QuickBooks Online data.
You are then given a refresh token (or access token depending on if you're using OAuth2 vs. OAuth1).
You then store that refresh token (or access token for OAuth1) and can use that token going forward to make your requests, unattended, without requiring the user to be involved at all.
Key take-away: You only need the user involved the VERY FIRST TIME you connect, and then never again.
I created a web application which will show all private videos of only one account.
Now I have to authenticate the account to get list videos. I saw 2 ways to authenticate by ClientLogin and Oauth. Which ClientLogin is deprecated and don't know how to use Oauth to authenticate the default account on server.
I have client_id and client_secret for my app.
I try this example but not working and i don't know what in $get['code'] and how can I put username and password of this account when using OAuth not ClientLogin.
It's pretty simple.
You can follow the steps at How do I authorise an app (web or installed) without user intervention? (canonical ?) to get a Refresh Token. At Step 8, choose the YouTube API instead of Drive API. Try to choose the most restrictive scope, eg. readonly. You can embed the Refresh Token (securely!!!!) in your app and then use it at any time to generate an Access Token. Thus the stored Refresh Token behaves like a username/password with restricted permissions.
Ask you have stated clientLogin is shut down you can not access any Google api using Login and Password. Your application needs to be authenticated
The thing you need to know about the YouTube API is that it does not support service accounts. You will have to use Oauth2. I am not a PHP developer but I have done this previously in C#. What you want to do is possible just a little tricky.
First off as I said you need to use Oauth2. I am hoping that this example is reasonably up to date if not the one for Google analytics is you may have to compare them a little.
Your script will need to be authenticated once using Oauth2. Then by requesting
$client->setAccessType("offline");
you will receive a refresh token. You will then be able to use this refresh token in your script on the server at anytime to request a new access token and access YouTube for that channel.
I'm building a very typical web app product. It will likely have corresponding mobile apps in the future. I'm building it from the ground up with a REST API, which is secured using OAuth2. I've got OAuth2 working, and I'm able to connect successfully using various grant types.
What I'm a little confused about is what grant types to use for the actual web app. Here's what I had in mind:
Public API access
Before a user logs into the web app, some API access is required for things like user registration and password resets. I was thinking of using the client_credientials grant type. A simple client id and secret validation in return for an access token.
However, it seems totally unnecessary to request an access to token for every single public request or even for each session. It seems to make more sense to just generate ONE access token that my web app will always use.
Yet, this seems to go against how OAuth is designed to work. For example, access tokens expire. What is the right way of doing this?
Private user API access
Next, for a user to login to the web app I was planning on using the password grant type (resource owner password credentials). This approach allows me to save the user_id with the access token—so I know which user is logged in. Further, by using scopes I can restrict access within the API.
I plan to save the access token within the PHP session. As long as the PHP session is active they will remain logged into the web app.
Is this an appropriate design for user login?
For Public API Access:
One method is to skip tokens all together and just use Basic HTTP Authentication for API access. You could accept Client Credentials for this, and limit what clients can do using client-specific scopes. Github offers HTTP Basic authentication using user credentials for all their API calls.
For Private user API Access:
This is an interesting question because it begins to breech the line between Authentication and Authorization. OAuth is used for Authorization, so logging in users becomes dicy. Session management, for example, is something not covered by the OAuth2.0 spec.
However, this is a common use of OAuth2.0 anyway. You can use the password grant type, or any other grant type for that matter, to obtain an access token. A major downside is they have to trust your application with their password (Not a big deal for your own app, but for 3rd parties not so much). Also, being logged in one place does not necessarily mean being logged in somewhere else (rather than SSO, you have "linked accounts", so the sessions are managed separately). One way around this is to ALWAYS send users to the oauth authorize endpoint, and if their session is active on the OAuth2.0 Provider side, reroute them back to the client app with an access token or authorization code. This way, if the session is active with the OAuth2.0 provider, the client can immediately log them in.