I am using Dotnetopenid for login.
I am logs in my application by using dotnetopenid provider suppose google.
At the time of logout I am ending the my application user's session by FormsAuthentication.SignOut(); but if I am not closing the browser and logs in using google it will not ask me for id-password and land me on secured page of my apllication.
Also, if i will try gmail.com it will directly lands me user account without asking id-password.
So how could I logout completely from my application and google too ?
thanks in advance
I think you are mistaking the Relying Party and the OpenID Provider. Using StackOverflow as an example, SO is the Relying Party and other sites (e.g. Google) are the OpenID Provider(s).
The Relying Party (e.g. SO) has no say in when the OpenID Provider (e.g. Google) chooses to "forget" the user for their own purposes.
EDIT: I was not familiar with the PAPE extension. However, if I understand correctly, it does not provide a way for the RP to say to the OP, "On your end, forget this user's authentication", which is what I think rehan wants. It just provides a way for the RP to demand another authentication for the RP's purposes.
I still see no way for (e.g.) SO to log a Google user out of Gmail after SO logs them out.
It sounds like what you're looking for is a Logout feature that will allow the relying party to also log the user out of the Provider at the same time.
DotNetOpenId doesn't offer this feature because OpenID itself doesn't have this feature in its spec. There's simply no way to do it right now. The OpenID community have had conversations about spec'ing out such a feature, but so far it's not there. If and when OpenID adds such a feature to its spec, DotNetOpenId will add support for it.
i had the same issue. So tried this.....when i logged out of my website which uses dotnetopenid, i also made a call to the following gmail logout link https://mail.google.com/mail/?logout&hl=en. This logged me out of gmail also.
https://www.google.com/accounts/Logout
try this one....
Related
From the recent I/O conference it was mentioned in one of the talks that account works in auth ui, this wasn't the case previously but is now also mentioned as a possibility in the docs
The FirebaseUI Auth component implement best practices for authentication on mobile devices and websites, which can maximize sign-in and sign-up conversion for your app. It also handles edge cases like account recovery and account linking that can be security sensitive and error-prone to handle correctly.
The feature however remains undocumented (from what I can figure out) for the time being (which is understandable since they have just launched it :)). But I was wondering wether anyone is clued in if this in fact is implemented and if so, how to use it?
They mean account linking when for example you sign up with Email A using provider 1 (google) and then try to sign in with a new provider 2(Facebook) which shares the same Email A, FirebaseUI will automatically link both accounts. Typically in that case, you would get an error that the credential exists. You would need to first sign back in with Email A using Google and then link the new Facebook credential to it. By doing so, the user is able to sign in with either providers in the future.
Our application can show rich links to webpages. So instead of a mere weblink we show a short summary and a picture. We used to use embed.ly's extract api to supply us with this data, but since they have changed their terms and pricing we have implemented an alternative solution.
The problem we find is that linkedin profile urls cannot be assessed by our new solution. Embedly was able to give us all the details we needed from a linkedin profile url (including the user's picture), but we don't seem to have access to that information without going through linkedin's API.
This call gives us all the data we are looking for:
GET https://api.linkedin.com/v1/people/url=[PROFILE_URL]:(id,email-address,first-name,last-name,headline,summary,formatted-name,picture-url,picture-urls::(original),site-standard-profile-request,public-profile-url)?format=json&oauth2_access_token=[TOKEN]
Where [PROFILE_URL] is a linked in profile url and [TOKEN] is the oauth2 access token.
There are two issues that I have:
Our application does not ask users to authenticate through linkedin, so we do not have a user oauth2 access token available;
Linkedin's suggestion in their FAQ (https://developer.linkedin.com/support/faq) seems very daft:
Can I get an access token for my application that doesn't require a member to login?
We do not provide access tokens for applications that are not associated with a particular LinkedIn member.
If your application requires you to make API calls in an automated way - without user interaction, you need to bootstrap the first access token request by manually signing in, and then ensure that your application refreshes the token automatically prior to expiry to avoid the need for additional human authentication.
Now... four questions:
a. Has anyone implemented option [2] in a production setting?
b. If yes, what are the limitations, downsides etc. Is this really the best and safest solution?
c. Is there any alternative that allows me to authenticate the application itself with its mighty client key and client secret?
d. Is there anyone from linkedin monitoring this? If yes, can you contact me?
Cheers, Raymond
My plan for this web app is that it needs the user to log in with LinkedIn, and the user's id on the site and database is their LinkedIn id.
So, the most convenient and elegant thing would seem to be to have no "native" login at all, and just have the user log in with LinkedIn from the start.
Having seen recent disaster for Twitter api developers, I now wonder if this is considered too risky. I am assuming that it is allowed by LinkedIn (haven't checked that yet).
Alternatives could be:
native login then login with LinkedIn after that.
OpenId login and then login LinkedIn after that.
Somehow have a backup login incase linkedin kicks me off.
Any thoughts on the main idea or alternatives? Any other ideas?
As soon as you require a user to create a native login, you're making the usability of your app more challenging IMO. I hate, hate, hate it when I'm forced to create a new account on a site when a single button press would work.
Of course, usability would be at near zero in the unlikely circumstance that LinkedIn's provider no longer works for your app. So, there are tradeoffs.
Does LinkedIn provide access to the user's e-mail address when you authorize them? If that's the case, you could just login with LinkedIn. If LinkedIn's provider no longer works for your app, you could send users an email with a temporary password in an authoritative way. If they don't provide an e-mail address via their provider, then you'll be forced to collect it separately directly from the user (and potentially verify it in case the user made a typo or something).
I asked various questions about my problem (here and here) and I also asked in the #oauth & #openid freenode's channel on IRC. (this is note an "UP" question, it's an other problem)
I'll sum up my project configuration : Anyone will have the possibility to create an app that can use my API. To start, I'll work on my API and a Web based app, but the documentation about the API will be public. It's a bit like Twitter API.
The problem I face is how can I be sure which user is using the API (to retrieve his personal data, like your tweets), even if the User is using an app that I don't know who make it (again, like twitter and all the apps around).
I googled a lot and with the help of the previous answers given, I took a look at OAuth.
As far as I understood the way OAuth works, here how :
A user visit an app that use my API (web, mobile, whatever)
The apps redirect the user to the API for the authentication (I'll use OpenId) and the authorization (OAuth). This is a bit odd since the API will have a web interface for the login and the authorization (I suppose this is how it works since Twitter do that)
The API redirect the connected user to the app, with some tokens. In these tokens, there is a token representing the user that the app must store in order to indicate to the API which user is using it currently (Am I correct?)
So far, everything goes well. But what I can't figure it out, is when the user quit the app and goes again : how the app can remember the user is the one that used it before ?
(Before some of you bring me the cookie answer, I'll remark this is a simple example, it would be the same if the user clear his cookies, format his computer or change its computer.)
The only solution I can find, is when an unauthenticated user (without a remembering cookie for example) goes to the app, the app redirect him again to the API to authenticate himself, but this time, the user won't have to re-allow the app (authorization) since it already did it. The API will then return the user to the app to allow him to play with this.
Is this the proper & secure way to do it ?
The #OAuth IRC channel told me about the new protocol, WebID, but this is currently in pre-draft mode and I don't want to use something that will change continuously in the future :/
Thank you very much for your help!
Short answer: OAuth results in an authenticated access token. That access token is tied to ONE user. And as long as the access token is valid. The third application can do whatever the API allows the access token to do.
Long answer:
The thing with OAuth is that it does not "Log in" a user. OAuth gives third party applications what is called access tokens which can be used to access data on behalf of a user whether he/she is logged in or not.
Many services restrict their access tokens. Twitter for example issues two types of access tokens, read-only, and read/write. But there is no concept of logging in to use APIs. While an access token is valid, a third party application can access the user's data, and change things without a user's explicit interaction.
Most API providers have functionality to revoke access tokens. That is what happens when you in twitter look at your Connections page . See the revoke access links?
Personally I love the OAuth approach. As an API provider, you can control what access tokens are allowed to do, and the user can kill bad applications from using his/her resources. OAuth is secure as far as authentication goes. Third party applications do not get hold of user's passwords. But once authenticated they can do whatever your API allows.
if we take a look at how Twitter works, I think the missing point is an other layer to the project: The Official website:
The thing is, when you want to allow any 3rd party application to use Twitter, this application redirect you to the OAuth page of the Twitter API, IF you are connected, but if you aren't, it redirect you to the login page, which is located at http://api.twitter.com/login
(I don't know if keeping the api in api.twitter.com for loging an user, instead of just twitter.com is correct, but this is just semantics)
So, the workflow would be:
A user goes to a 3rd party application (like a website)
This third party redirect the user to the API for Authorization
The API redirect the User to the website for Authentication first
The official website redirect the User to the OpenId provider (or Facebook connect)
The Authentication is made (via multiple requests)
The website redirect the user to the API after he's successfully authenticated
The user allow/disallow the permissions asked by the 3rd party apps
The API returns to the 3rd party apps.
The User can now use (or not) the application.
This implementation have 2 problems:
Every time an User ins't authenticated (cleared it's cookies, connect himself from an other computer, etc), he will have to go through the Authentication method, by being redirected to the Official website and then being redirected to the 3rd party application (the API would be transparent, since it has already allowed the application to access his data).
All those layers would certainly lost the User on the Authentication process with too many redirections.
A possible solution would be to store the user's access_token, for example in the case of a mobile app, but with a pure html/css/js oriented app, this isn't possible. A login/password in the 3rd party web application that would match the user to the access_token of the API would be an other solution, like Seesmic (I think), but this is just useless (for us, not Seesmic) : the idea of not having the user's password become useless.
This is a possible explanation but I would require more details on how this is possible and your thought about that solution. Would it work?
(I added this as an answer since it's an (incomplete and not so sure, I agree) one.
Can we build applications on top of the twitter user base?
Is it just another open id or something more?
I noticed when using twitpic and some MUD type game 14mafia.com that it uses my twitter login (it tweets on your behalf).
If they are using my login/password that's pretty crazy, I mean what kind of security is that?
Anyhow, just want a developers who has expereince to tell me if we can re-use their membership like openid?
Can we build applications on top of
the twitter user base?
The Twitter API is described at http://apiwiki.twitter.com/
Is it just another open id or
something more?
Twitter is neither an OpenID consumer nor provider.
I noticed when using twitpic and some
MUD type game 14mafia.com that it uses
my twitter login (it tweets on your
behalf).
If they are using my login/password
that's pretty crazy, I mean what kind
of security is that?
Awful security. Don't give out your password to third party sites. Some just use the password anti-pattern, others will steal your credentials for purposes you don't want.
Twitter supports OAuth today. If a site wants to do things with your Twitter profile, it should use that.
Anyhow, just want a developers who has
expereince to tell me if we can re-use
their membership like openid?
No, you can't.
Twitter offers both OAuth and simple username/password authentication in its API. Originally they only had the basic authentication API so many early apps were built using it. Later, they added the OAuth support, but since it was easier to use the basic authentication, many twitter clients and apps still use it.
You can tell which one an application is using, because if they are using the simple authentication they will ask for your password. You have to trust them with it in that case. You're right that it's poor security.
I imagine they are using the Twitter API.