4

If BASIC authentication was not build to handle logging out, what alternate authentication methods exist for authenticating backend services that need to be able to log out?

I found these references stating that BASIC auth is not able to do log out without some hackiness:

How to log out user from web site using BASIC authentication?

How do I log out?

We are using BASIC authentication to log into backend applications, and FORM authentication for frontend applications. After our team tested the stack on FireFox/IE, it was found that a user would not be able to log out if they logged into the backend services via BASIC authentication on those browsers. The hacks and workarounds are unacceptable to my team (asking user to enter incorrect credentials, making user close browser, use javascript to send incorrect credentials, ask user to clear browser cache, etc), so we are seeking advice on alternative authentication methods that DO allow logging out

EDIT- My temporary workaround for logout:

I am currently getting around this problem by using FORM authentication. One problem is that my backend services rely on the shared frontend login.html form, and another problem is that Postman does not support logging in via a redirected FORM input, and our client Arquillian calls blow up from the login form.

FORM authentication gets rid of the "I can't log out with BASIC" problem, but now I can't authenticate as straightforwardly.

GuitarStrum
  • 713
  • 8
  • 24
  • If multiple backend services rely on the shared frontend, then you may want to explore session sharing. Some options are there like hazelcast. You can also explore JSON web token. – Vikas Sachdeva Jul 17 '18 at 04:20
  • Yes we already have session sharing via the app server. We just need a better way to send our credentials while still being able to log out. Will have to look into JWT. – GuitarStrum Jul 17 '18 at 04:23
  • [This provides a lot of workarounds](https://stackoverflow.com/questions/233507/how-to-log-out-user-from-web-site-using-basic-authentication). Why are such workarounds not acceptable? What are you asking is even bigger workaround so what makes it acceptable? – Piro Jul 17 '18 at 04:26
  • @GuitarStrum In that case, invalidating the session on logout is not serving the purpose ? – Vikas Sachdeva Jul 17 '18 at 04:48
  • @Vikas no. Even though we invalidate the session, basic auth will reauthenticate the user since the credentials are stored in the browser and a new session will be created. – GuitarStrum Jul 22 '18 at 03:27
  • @Piro our product is not allowed to rely on the frontend to provide main security operations like making sure a user is logged out. Credentials must have a reliable way of being purged from the browser, something basic auth does not consistently support across browsers. Also, even if we used the workarounds, they do not work in Safari. – GuitarStrum Jul 22 '18 at 03:29

2 Answers2

3

Form based-authentication

If it's okay to keep the session state on the server, you can go for form-based authentication.

Send the credentials in the form, if the credentials are valid, the server will issue a cookie that will be sent back and forth to identify the session on the server. To logout, the session can be invalidated:

session.invalidate();

You also can configure your application to expire the sessions due to timeout:

<session-config>
    <session-timeout>60</session-timeout> <!-- minutes -->
</session-config>

Token-based authentication

If you want a stateless mechanism, go for token-based authentication.

The client exchanges hard credentials (such as username and password) for a piece of data called token. For each request, instead of sending the hard credentials, the client will send the token to the server to perform authentication and then authorization.

For the token, you could use JSON Web Token (JWT). It's an open standard that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

JWT is a generic name for the following types of token:

  • JSON Web Signature (JWS): The payload is encoded and signed so the integrity of the claims can be verified.

  • JSON Web Encryption (JWE): They payload is encrypted so the claims are hidden from other parties.

The image was extracted from this page.

The token can define an expiration date in the exp claim. For logout, you can remove the token from the client.

You also could keep the track of the tokens in a whitelist on server-side and invalidate them as you need. There's no need to store the whole token on server side though: Store only a token identifier in the whitelist and use the jti claim to store the token identifier in the token.

Sandra Rossi
  • 11,934
  • 5
  • 22
  • 48
cassiomolin
  • 124,154
  • 35
  • 280
  • 359
  • In token-based authentication what happens when admin blocks an user account and the user has to be logged out immediately? – jenil christo Jul 20 '18 at 13:24
  • @jenilchristo If you keep the track of the tokens on a whitelist on server side and check them and validating the tokens, you can simply remove the tokens for a given user from the whitelist. – cassiomolin Jul 20 '18 at 13:27
  • Any other alternative without storing a whitelist or blacklist tokens to the database is available to solve the problem? – jenil christo Jul 20 '18 at 13:47
  • Is it safe to just remove the token from client when doing a logout ?.The token could still be used by attackers, until it expires right? – jenil christo Jul 20 '18 at 13:52
  • @jenilchristo If you don't want to whitelist or blacklist the tokens, the only thing that comes to my mind is changing the key used to sign/verify the token... – cassiomolin Jul 20 '18 at 13:53
  • But changing the signature will invalidate all the users or tokens right..? – jenil christo Jul 20 '18 at 14:15
  • @jenilchristo I have no idea what your requirements are. Please [ask a new question](https://stackoverflow.com/questions/ask). – cassiomolin Jul 20 '18 at 14:29
0

I suggest you to have a look at Apache Shiro, especially the way session are managed (https://shiro.apache.org/session-management.html). They have namely abstracted the concept of session so that it can work in various situations: in a webapp (in such case, it's simply a wrapper around the HTTP session), in a standalone app, etc... In your particular case, the front-end could open and close (logout from) a Shiro session that is shared with the backend layer.

See the sentence:

Heterogeneous Client Access

(...)
For example, a (desktop) application could ‘see’ and ‘share’ the same physical session. We are unaware of any framework other than Shiro that can support this
TacheDeChoco
  • 3,683
  • 1
  • 14
  • 17