0

I'd like to allow users of a web application with bcrypted passwords and session-based authentication the ability to grant our tech support team access to their account for a time, with the option to manually revoke access. Is there a secure way to approach this problem?

I'm using a LAMP stack.

Ideally, the access could be granted manually (such as when a user is on the phone with us) or automatically (such as when a user emails us via our application or posts in our support forum).

One approach I can imagine would look like this:

  • The user clicks a button in the application to allow tech support access to their account.
  • The browser would send a request to the server that would store the user's session identifier, CSRF token, etc. in our support database.
  • The support database would let support technicians find the customer they are speaking with, and subsequently use the same session identifier, etc., to log in to the user's account.
  • Manually revoking access would remove the session identifier from the support database.

But, it necessarily limits the tech support to the session length, which may not be long enough—especially in the case of email support.

Is there a better or more standard way of approaching this problem?

EDIT 1: I could do something like generate a new token that would allow a technician to login via a backdoor, but I'd prefer to avoid backdoors if at all possible.

I suppose another possibility would be to give a wide-open backdoor that's only accessible via an SSH tunnel to the servers. Still a backdoor, but at least very limited in who can access it.

David Alan Hjelle
  • 942
  • 1
  • 10
  • 23

1 Answers1

1

I'd like to allow users [...] to grant access to their account for a time, with the option to manually revoke access.

You are describing delegated authorization. The OAuth protocol is designed for exactly this, and is more secure.

In OAuth 2.0 terms, the end user is a resource owner, and the system that tech support reps use to access a user's account is called a client. OAuth provides a way for a resource owner to grant a client access to his resources at a resource server. After the authorization process, the client receives an access token.

The access permissions associated with the client's access token have a scope, which defines the degree of access authorization the client has for the resource owner's (the end user's) resources. This is more secure than your solution to share the session ID because (1) there is no sharing of secrets between parties, (2) client access is not tied to the user's session, and (3) the client's access scope can be restricted so that he only has partial access. Access tokens can be revoked at any time; perhaps by the resource owner or expiration time.

You should read the OAuth 2.0 specification to learn the technical details of how authorization is granted and how access tokens are issued and used.

Community
  • 1
  • 1
Andre D
  • 4,585
  • 1
  • 19
  • 26
  • Thanks, Andre D! I had wondered if OAuth was something useful, but I didn't know the appropriate terms. I will read up on that. Out of curiosity…do both OAuth 1 and OAuth 2 support delegated authorization? – David Alan Hjelle Jun 07 '13 at 01:27
  • @DavidAlanHjelle, OAuth 2 is very different from its predecessor, but they both accomplish more or less the same thing. http://stackoverflow.com/questions/4113934/how-is-oauth-2-different-from-oauth-1 – Andre D Jun 07 '13 at 01:38
  • BTW…I will likely accept your answer, but I want to review OAuth more in detail first, so it may be next week sometime. Thanks again! – David Alan Hjelle Jun 07 '13 at 14:43