Best practice for Immediate Request / Reauthentication of user

[Sven Jacobs]

I'm new to OpenID and recently started to use OpenID4Java in a GWT project.

When the user visits the application for the first time the authentication process works fine. In the OpenID callback I receive the user's email address and use it to match it against local users and perform authorization. I store the email in the HTTP session so that I don't have to do authentication again during the lifetime of the session. Additionally I store the "verified ID" in a custom, long-lived cookie (as mentioned in the best practices http://wiki.openid.net/w/page/12995223/Relying%20Party%20Best%20Practices#StoreprimaryOpenIDinacookieandcheckimmediateatnextsession).

Once the session invalidates I have to reauthenticate the user. Although I could increase the lifetime of the session or implement my own session management (not recommended, I know) this is by design. I want the application to reauthenticate the user because maybe in the meantime the user has revoked access for the application?

So if the session has expired I take the "verified ID" from my custom cookie and perform an immediate request (see http://openid.net/specs/openid-authentication-2_0.html#anchor28). As far as I understand it the setup is basically the same except

    manager.setImmediateAuth(true);

So the OpenID URL is opened but instead of a permission dialog the callback URL is called immediately if the user has granted access for the application previously. However that means that every time a user opens the application and the session has expired, the OpenID popup window opens and immediately closes again.

I wonder if it's possible to do the immediate request completely on the server-side without the browser redirection (invisible to the user)? However I still need the OpenID attributes that are usually passed to the callback.

How do other applications reauthenticate recurring users with minimal user impact?

[Johnny Bufu]

On 13-07-22 06:47 AM, Sven Jacobs wrote:
> In the OpenID callback I receive the
> user's email address and use it to match it against local users and
> perform authorization.

Attributes in an openid response are self-asserted, so unless you have
other means of verifying that the user is actually the owner of the
provided email address, your accounts can be hijacked by anyone
declaring that they own a certain email address. (Some openid providers
do provide a "verified email" attribute, but this should be a conscious
decision on the RP side to trust such an assertion.)

RPs should identify the users by their identifier that comes in the
openid.claimed_id response field.

> So if the session has expired I take the "verified ID" from my custom
> cookie and perform an immediate request (see
> http://openid.net/specs/openid-authentication-2_0.html#anchor28). As far
> as I understand it the setup is basically the same except
>
> manager.setImmediateAuth(true);
>
> So the OpenID URL is opened but instead of a permission dialog the
> callback URL is called immediately if the user has granted access for
> the application previously. However that means that every time a user
> opens the application and the session has expired, the OpenID popup
> window opens and immediately closes again.
>
> I wonder if it's possible to do the immediate request completely on the
> server-side without the browser redirection (invisible to the user)?

No, this needs to happen on the front channel, where the user's browser
can present the authentication cookie to the openid provider (if they
still have an active session there). You can put it in a hidden iframe.

Johnny

[Sven Jacobs]

Am Montag, 22. Juli 2013 19:33:27 UTC+2 schrieb johnny.bufu:

On 13-07-22 06:47 AM, Sven Jacobs wrote:
> In the OpenID callback I receive the
> user's email address and use it to match it against local users and
> perform authorization.

Attributes in an openid response are self-asserted, so unless you have
other means of verifying that the user is actually the owner of the
provided email address, your accounts can be hijacked by anyone
declaring that they own a certain email address. (Some openid providers
do provide a "verified email" attribute, but this should be a conscious
decision on the RP side to trust such an assertion.)

RPs should identify the users by their identifier that comes in the
openid.claimed_id response field.

Ah, good to know! Then I will use the claimed ID for authorization.

But that ID doesn't seem to be verify user-friendly or easy to remember. Let's say an administrator of my applications wants to create a new user that is authenticated via OpenID. How does the admin (or the user) get the user's claimed ID?

[Sven Jacobs]

Read about it a bit more and I think I know how to solve this problem:

A claimed ID is unique per application. So even if I know the ID of application A I cannot use it for application B.
What I can do however is when a user authenticated via OpenID, create a new local user with that claimed ID but leave the user disabled by default. An administrator then has to enable that user.