When I try to authenticate a user through Google OAuth 1.0, if the user is already logged in with Google, he's automatically asked if he'd like to allow access to my application. I would like to force the user into submitting his/her credentials again to Google, so he may provide a different account than the one he's logged in with (both FB and Twitter OAuth handshake have an option for this).
Also, is there a parameter I can pass on to Google that would make it aware it's in a popup, so it may adjust the layout better ? Again, FB and Twitter take "ownership" of the popup and resize it so their layout fits perfectly. They're also aware of being presented in a popup so a different layout is presented.
Google seems so far behind with its API's. I found the overall implementation difficult to work with, the XML's are creepy and full of useless data, documentation incomplete and overall procedures are not consistent across it's services, or even across the same service!
Try adding max_auth_age=0 to the first OAuth URL. This worked for me.
Related
I don't believe I need OAuth
Then again, what do I know
All I want to do is take someone's credit card information and charge them. I am not accessing other people's QuickBooks accounts (only my own) and I am not trying to access any other personal information other than what they input into my form. For this reason it seems absolutely asinine to think that I'd have to redirect them to intuit.com and force them through an OAuth prompt (what account would they even be authorizing? They probably don't have a QuickBooks account)
I've spent the last hour reading through QuickBook's API documentation and I've run in circles and found the whole thing utterly confusing. Every page which references a particular API endpoint makes no mention of authentication -- only the headers, query parameters, and request body that are expected. The API explorer does not show any form of authentication in their examples:
No basic auth header, nothing in the request body with an API token,.. nothing
Checking the console while hitting submit isn't any more helpful. The request gets sent to their back-end server where it does the real request:
It even includes "apikey", "apisecret", and "oauth" attributes in the body which are all empty -- it acts like the endpoint doesn't even NEED authentication.
Out of dumb curiosity I tried making the request with no authentication to see what would happen:
401 Not Authorized. So some authentication is needed. I continued to scour the docs and turned up nothing but page after page linking me back to OAuth and saying that I need to set up OAuth. Why do I need to set up OAuth to take a credit card number that was given to me and hand it to QuickBooks?
I even tried looking at their sample app. The "take the code for a test drive" (https://developer.intuit.com/v2/ui#/emulator?workflow=ecommerce) was utterly worthless. It only gave me some pseudo-code with zero idea for how to handle authentication:
I even looked at the actual code and don't see anywhere that they provide an API key or secret key.
I'm pretty much ripping my hair out at this point, so I think I need someone with experience to point me in the right direction.
I don't believe I need OAuth
You do.
For this reason it seems absolutely asinine to think that I'd have to redirect them to intuit.com and force them through an OAuth prompt
You misunderstand what OAuth is, and how it's used.
OAuth is used to get YOUR auth tokens so that YOUR COMPANY can authenticate to Intuit and identify itself so you can charge customer credit cards. YOU are redirected to Intuit's website to authenticate ONCE, and ONCE ONLY, and then NEVER AGAIN.
You store the tokens you get back from the one-time OAuth pop-up window process, and use those for all future HTTPS requests.
The end-user (i.e. your customer) is NOT redirected.
If you're familiar/used to something like Authorize.net or other web services, where you open a web browser and go to a website and copy a secret key/API token into your code... this is the exact same process except instead of you logging in and manually copy/pasting an API token/key, you're logging in and the OAuth process automatically gives you the API token/key programatically.
I'm working on an internal website for the company I work for. The website will be only available to company staff. We use Google Apps for Business, so we would like authentication to be done using our google accounts.
I've gone through 'google sign in' samples from here: https://developers.google.com/+/
It works, but the problem we run into is that it requires the user to sign up to Google+. This is a speed bump we would prefer not to have.
Are there any ways around this? Thanks.
It shouldn't be too hard to roll your own sign in using the lower levels of Oauth, eg 'email' scope. It's hard to give a more specific answer because it depends on your architecture (eg. are you predominantly server-side or client-side) and what kind of session do you want to create by the sign in process. For example, if you are client/REST based, you probably don't want any session at all as REST encourages statelessness. On the other hand, if you are more web based, serving static pages, you will want a session.
In simple terms, you will be doing something that generates an access token, and then processing that access token to determine the email address (or Google ID) of the person who created it. You will then establish some sort of session (eg. using session cookies) that identifies future requests from that user.
Feel free to add some more detail to your architecture and I'll try to finesse the answer.
For simple http servlet sessions, it will be something like.
User requests a protected page
servlet detects that there is no session and/or session has no authenticated user
servlet redirects to an Oauth page to request an access code. something like
https://accounts.google.com/o/oauth2/auth?redirect_uri=xxx&response_type=code&client_id=zz&approval_prompt=auto&scope=email
NB research the exact URL, don't rely on this to be exact
If the user isn't logged on, he'll be prompted; if he has multiple logins, he'll be prompted; if he hasn't yet granted email access, he'll be prompted. If none of these conditions are met (the normal case) he won't see anything.
Browser will redirect to the redirect_uri, carrying an access token (or an auth code if this is the first time the user has used the app)
Post the token to the Google userinfo endpoint, and you will receive a decode containing the email address
Store the email into a session object (or retrieve your own user object and store that)
redirect back to the originally requested page. You can use the OAuth state parameter to pass that around
et voila. all future page requests from that user will be within a session containing some user identification.
NB This is just an outline and I may even have missed a step. You will still need to do your own OAuth research.
Apparently not:
(..) if a Google user who has not upgraded to a Google+ account clicks
on the Sign in with Google+ button, the same consent dialog that opens
will take the user into an account upgrade flow.
Weirdly the docs for OAuth2 states:
Google+ Sign-In works for all users with a Google account, whether or
not they have upgraded to Google+.
I was reading through the windows live developers doc here. In that I saw they are having an authentication method something like this.
GET https://oauth.live.com/authorize?client_id=CLIENT_ID&scope=SCOPES&
response_type=RESPONSE_TYPE&redirect_uri=REDIRECT_URL
I understood everything except for where do I give the username and password of the user?
I am planning to create an app(first one in my life) to learn the working.
I also have never used or coded something over REST.
When using OAuth, your application never receives the user's username or password. Rather, the user logs in to Windows Live on the Windows Live servers and authorizes your application for access to their information. After they have authorized your application, you receive an access token from Windows Live on behalf of the user. You then use that access token with the Live API to retrieve user information.
Coding something using REST protocols isn't anything too terribly complicated. It has been my experience that you're just specifying parameters to the API using GET or POST as your request method. Adding OAuth on to your requests is a matter of specifying additional parameters.
You're task is to learn two things here since you've never done REST or OAUTH before. Spend time looking at both.
Oauth is hard to get and hard to implement.
You should choose an off-the-shelf Oauth library they exists for most languages.
(Then you do not have to worry about the details. OTOH: You should know how it works to know how to set up and fix if something goes wrong.)
http://oauth.net/code/
Which are the steps must I follow to implement a token authentication in my web page?
Any summary or links will be appreciated.
I want to implement similar to Facebook or Google, first time client loggin and receive token and then use it in next actions.
I read also about OAuth but I don't want to give access to my application from 3rd party.
Thanks for the long response and it seems clear to me I need to read more about this.
What I want is to know the "steps" to implement a basic web application that uses token authentication. That is user logging once and then can make some actions: add content, edit, etc.
I know what I'm saying is similar to a session, where server adds a SESSION_ID on the HTML header and later request are identified and associated with that session. I read sessions way isn't good to scale so I want to implement a similar system like gmail or facebook before they go to OAuth. Probably I'm talking about something similar to oauth (i don't read in much depth) but witj two-legged instead three-legged.
You should think about your requirements, pick an appropriate protocol and some decent piece of software that implements it.
It's really hard to say more without more details:
are you talking about authentication for one or for multiple web applications? do you need single sign on between different web applications?
should all user data be stored on your server or should user be able to login e.g. with the google account?
should the token contain informations about the user?
on what platform are your applications developed?
what authentication method should be used?
do you want to realize a portal?
There is a really wide range of protocols and tools which might or might not fit to your requirements:
http://en.wikipedia.org/wiki/Category:Authentication_methods
http://en.wikipedia.org/wiki/Category:Identity_management_systems
I personally like CAS ( http://www.jasig.org/cas) for token-base SSO between multiple web applications. It's Java based but also has some support for PHP and .Net.
OpenID is fine, if you want to allow users to login with their Google, Yahoo, whatever account (configurable...) and don't want to store user information by yourself.
Kerberos/SPNEGO is the way to go if you want to haven integrated windows-sso for your corporate intranet applications.
For university applications SAML/Shibboleth probably is best. Outside universities it's somewhat less popular, probably cause it's a fairly complex protocol.
Oh and I almost forget: Most of the web frameworks/standards have there own version of plain-old "form based authentication". Where a user goes to a login form enters its username and password. Both are with or without SSL transported to the web/application server. The server validates it against some kind of database and gives a cookie to the user, which is transmitted and validated every time the user sends a request. But beside all this shiny protocols this seems to be pretty boring :-)
And before doing anything with web authentication, you might think for a moment about web security in general ( http://journal.paul.querna.org/articles/2010/04/11/internet-security-is-a-failure/ http://www.eff.org/files/DefconSSLiverse.pdf) and what you can do to not make it even worse on your site ( http://www.codinghorror.com/blog/2008/08/protecting-your-cookies-httponly.html http://owasptop10.googlecode.com/files/OWASP%20Top%2010%20-%202010.pdf).
see your point.
On the protocol level a very simplistic token approach is HTTP Basic Authentication. But this often doesn't fit, as there is no logout function etc.
A custom, simple cookie based approach can for example look like this:
The server generates some kind of secret (a value that is hard to guess)
When a user tries to access a protected resource, he is redirected to a login form
after successful authentication he gets a cookie. This cookie contains three values: username, timestamp and a hash of {username server-secret timestamp}.
with every user request the server recalculates the hash values and compares it to the value which the client sends in its cookie
(needs more consideration of: httponly and secure flag, transport layer security, replay attacks etc)
Amazon S3 stores its authentication token in an HTTP Header and uses HMAC for calculating it. It's described here: http://docs.amazonwebservices.com/AmazonS3/latest/dev/index.html?S3_Authentication.html (Not necessarily recommended for using with a browser based web application)
If there is a book about REST anywhere near you, you may look if it has a chapter about authentication. Probably things are much nicer explained there than here :-)
There are some frameworks which are capable of doing this kind of authentication. For security reasons it would make sense to check them first before implementing your own stuff.
I'm trying to add a "share via twitter" link to our website. I'm aware of the standard http://twitter.com/home?status=TWEET method, and it works good enough for my purposes when the user is logged in to twitter already.
If, however, the user is not logged in, twitter displays the login form first (which is only reasonable). After the login, the home screen is displayed without the tweet content.
Am I missing something obvious, or is this a know flaw in this method? If so, what is the easiest way (apart from using services like TweetMeme, which I noticed asks for login in advance) to make the share button work as expected?
If the user is not signed in when accessing http://twitter.com/home?status=TWEET it seems that the status is indeed forgotten. This would be a Twitter website issue and not something you're doing wrong.
Update: Use this URL instead: http://twitter.com/intent/tweet?text=TWEET
TweetMeme, on the other hand, uses its own Twitter "application" via the OAuth authentication, requiring users to log in before retweeting using TweetMeme, and is smart enough to include the tweet message in the OAuth callback URL so that it's not forgotten.
So really, you can:
Use TweetMeme, where the user would have to log in, but at least have the tweet be remembered once that's done;
Create your own Twitter application that uses the same tweeting functionality as TweetMeme; or
Use Twitter.com's less-than-desirable status updater and hope the user is logged in, or hope that they're smart enough to click the back button a couple times and click on your link again if needed.
Just use the following url and parameters
http://twitter.com/share?text=YOUR-TEXT&url=YOUR-URL
Then it works.