Hot answers tagged

88

Consider the first case. Each client gets a random ID that lasts for the duration of the session - which could be several days if you like. Then you store the information relevant to that session somewhere server side. It could be in a file or a database. Let's suppose you pass the ID via a cookie but you could use the URL or an HTTP header. Session IDs/...


25

The answer to your question can be at the code level, protocol level or architecture level. I will attempt to summarize here most of the protocol level issues since that is usually critical in pros and cons analysis. Keep in mind that OAuth2 is much more than Resource Owner Password Credentials which, according to the specification, exists for "legacy or ...


14

It sounds like there are two goals: Easy for end-users to authenticate with their existing social accounts Easy for developers using your webservice Authorizing people to use resources on your site makes OAuth2 a preferred mechanism due to the popularity and availability of client libraries. 1. Easy for end-users to authenticate with their existing ...


10

OAuth is not about exposing an API. OAuth is about authorization: Is Site B allowed to access User A's resources. Before twitter began implementing OAuth, it used HTTP Basic auth. That meant users had to give their credentials to third party websites / services to allow them to access their data. This means that the website now has unlimited access to the ...


10

Why is it holding the secret? The app should never be holding the secret. Your back end (or the validation service you're using) for performing the authentication round trip should be holding the secret and nothing else should ever contain it. The client ID needs to be available for the user, it's what they use to know what they're authenticating for so ...


8

Yes somebody could potentially see this token in the packet, which is why it is also a good idea to use SSL encryption of all network traffic before and after authentication and distribution of a token. Someone on an unencrypted wireless network, like at a Starbucks use this method all the time to pick up packets to services like Facebook that do not ...


5

How to make it extensible First you should notice all these api's use the same mechanism for logging in. They all use OAuth for their authentication. This you need to leverage by starting with a general OAuth library. Don't use their own libraries for authentication, these will be unusable for other providers. If you get the hang of OAuth2 it is quite easy ...


5

The primary benefit to using ACS is that you can integrate login systems which are not compatible with DotNetOpenAuth; namely, that you could combine external logins with an Active Directory (including both on-premises AD as well as AD in the cloud like Office 365). Your customers could use their accustomed identities from 3rd parties, and your ...


5

Ask yourself why you need to invalidate the original token. A user logs in, a token is generated and off the app goes. The user presses logout, a new token is generated and replaces the original token. Once again, all is well. You seem to be worrying about the case where both tokens hang around. What if the user logs out and then somehow makes a request ...


4

OAuth is an open standard that does not require users to give their credentials away to several different sites. They only give their credentials to one site, then the other sites can authenticate their users with your site without asking for a username/password. You've already seen this benefit when logging into your account here. You could implement your ...


4

This will help . You will just get the concepts regarding web services . IMAP , SMTP but not for specific language . https://developers.google.com/google-apps/gmail/


4

Redirects happen transparent to the calling JavaScript. Detecting a redirect from JavaScript is not (universally) possible. However, there are two things you can do: Detect the returned data is not JSON (but HTML) and re-open the URL using a popup or iframe, and handle the authentication. Modify your web API to return a 401 Unauthorized header for invalid ...


4

You can very well use OAuth 2.0. OAuth gives you various grant_types to support various use-cases. The use case you have will have grant_type = password, this is a 2 Legged flow, unlike the 3-Legged where there are 3 parties involved, ie. resource_owner (enduser) Client (third party app) Resource server (Server) as Server & your mobile application ...


4

Eh, answering my own question... I followed up a bit more on UMA, and it seems to be indeed some kind of a possible solution: UMA seems to be a semi-official (or at least the only official-looking one I could find) extension to OAuth 2.0, adding support for "fine grained", M:N sharing of resources. In simple words, it allows a scenario such as: "Alice ...


3

I believe you are misinformed about the encryption around GET variables in a URL The only people that can view the GET variables in a request are the original computer and the receiving server (link). Only the DNS lookup based on the domain the HTTPS request is sent to is not encrypted. Everything else, the ports, the GET variables, the resource ID, is ...


3

Your performance gain are going to come from Scaling up, (if you need to). Imaging you have a whole lot of users Option 2 would cause server side bottle neck much sooner than option 1. Small scale where the server would have no problem with the load, the performance gains would be negligible.


3

Section 4.6 of RFC 5849, which defines OAuth 1, states that the consumer secret was never intended for use by desktop consumers, despite Twitter's use thereof in practice. As Nelson Elhage pointed out in "Dear Twitter", Twitter can and does terminate consumer keys of desktop clients, provided that the client isn't too big to fail. But there are two ...


3

I may be wrong, but if you bundle keys with the desktop or mobile app, open source or not, it is possible to access them. If services like Twitter and Tumblr force us into using OAuth-only API, we have two options: setup an auth proxy service for every app bundle keys with the app The former is more difficult and costly, not necessarily maintainable for ...


3

Basic authentication is not a good way to secure your REST API. I explained the reasons why in this answer. When you build a REST API, you are implementing the resource server in OAuth2 terms. All your API needs to do is validate that the token passed along with the request in the Authorization HTTP header is valid and from a trusted issuer. See this link ...


3

You can handle the JWT issues you mentioned by storing a salt value along with the user and using the salt as part of the token for the user. Then when you need to invalidate the token, just change the salt. I know it's been a couple of years but I would actually do this differently now. I think I would ensure that access tokens had a relatively short-lived ...


2

While I have not yet implemented it I do intend to and have read through both the OAuth 1 RFC and OAuth 2 draft several times. Unlike OAuth 1 RFC the OAuth 2 draft goes into quite a lot of detail as to how to implement the server and you will find all the details you need in the draft. What you will need to first figure out is your target group of clients ...


2

It doesn't look wrong at the level you are describing; there are certainly sites that offer both types of login (e.g., SourceForge). When you're dealing with this sort of thing, you're absolutely right to cache the information in the session; re-querying the oAuth provider on every operation would suck in terms of performance, and it would also be tricky to ...


2

Oauth supports different Grant Types for the differing communications you're asking about. Here is an example in a PHP library , of a different grant type or two: Client Credentials Grant Type Trusted Clients and UnTrusted Clients The Client Credentials grant type is used when the client is requesting access to protected resources under its control (i....


2

Oauth (not sure about Oauth2) gives 3rd party access to resources using combination of consumer key and access token. So, for 2 party communication, you could bend it to only use consumer key without (or empty) access token. This will only give you a way to authenticate requests by using Oauth Authorization header. Then, what you use as consumer key is up ...


2

I had a similar problem a couple years back, and I found this article to be incredibly helpful. http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/ The basic idea is to have the client and the server to have a shared secret. That shared secret is never communicated over the wire, but is used to create a token (HMAC) that ...


2

OAuth2 defines a grant flow called client credentials grant. This allows an application to authenticate as itself and acquire an access token from the authorization server. It requires the client to register itself (get a client id) and create a client secret. It seems that the API you're using does support this.


2

If my understanding is right, then it's not possible for me to make an application that uses OAuth and has no server-side component, because turning the auth code into an access token requires supplying the client secret. If I put the client secret in the front end code, anyone could just pull it out and do shady stuff disguised as me. Is that ...


2

I would not share a secret. I would use asymmetric encryption like RSA and have each service generate a key-pair, then share their public keys with each other. That way they can both validate and sign JWTs created by the other as needed.


1

It's either secure or not secure. No more, no less. Having base64 doesn't make Basic Auth (or anything) more secure. There's nothing wrong in sending anything unencrypted if it's using encrypted pipe like Https. OAuth has more features, use it if you need it. For anything else, e.g. banking, using basic challenge-response is fine and secure.


1

It's an error for the user to attempt to authenticate twice, e.g. via HTTP Basic Auth and then via Post. I believe that this is to avoid specifying what should be done if the user sends two different client_ids via two different authentication methods - rather than specifying which authentication takes precedence, it's simpler to forbid this scenario ...


Only top voted, non community-wiki answers of a minimum length are eligible