checkSession always return 'login_required' on localhost

Help
, , ,
1

Hi all,
I have been using the latest version (9.10.0) of auth0-js and I am following this doc: https://auth0.com/docs/quickstart/spa/angular2/05-token-renewal

this is the code I have:

RenewToken() {
    console.log('renewing token');
    this.auth0.checkSession({redirectUri: 'https://localhost:8080'}, (err, authResult) => {
        if (err) {
            console.log(err);
        } else {
            console.log({authResultRenewal: authResult});
            this.tokenService.Save(authResult as TokenModel);
        }
    });
}

I have checked that chrome is allowing 3rd party cookies option, I have also confirmed that auth0 allows my locahost origin. I am not using any third parties social connection, just auth0.WebAuth for login with my own login page. Is there anything that prevents us from testing this on localhost?

2

The provided information is not sufficient for a definitive response, but one possibility is that you are requesting API authorization (audience parameter) and consent is required because it won’t be skipped for localhost (https://auth0.com/docs/api-auth/user-consent#skipping-consent-for-first-party-applications).

Since consent is an interactive step and you are issuing a non-interactive authorization request the response would indeed be login required.

For this particular situation this ends up being the solution, but this also applies as a general recommendation; you should avoid using localhost for development purposes. It does not provide you with any noticeable benefits and only means that your development experience is deviating from the production environment.

3

Hi mate, I have tried that skipping consent doc that you sent with no luck. I keep getting login_required. I dont think I should deploy this in order to test this during the development process. There must be a way of getting this to work. The logs in the Auth0 Dashboard register the issue but they dont seem clear enough. I have also tried ngrok to have a proper domain but the very same error keeps happening. By googling this, I have found many people with similar issues to this, however most of them are using google or facebook for authentication. I am really not sure what else to try. Do you have any other suggestion?

4

I referenced the doc just for reference purpose; you’re correct that you won’t be able to skip consent for localhost.

I may also have expressed myself incorrectly; I agree that you should not have to deploy this to an online hosting service or other to have this working. What I meant was that you should not be using the localhost name to resolve your locally running server. For example, you can define app.example.com in your hosts file to map to 127.0.0.1 which would give you the same outcome as localhost without using the localhost special name which is what leads to consent being required.

5

Yes, I tried that. I followed that doc, I changed my host file to myapp.example as per the document, I changed my webserver to respond to myapp.example, I added this url to the allowed web origins in Auth0 dashboard, I am not using social logins (facebook or google) and I still get login_required.
I seriously dont know what else to try. Surely there must be a solution for this

6

I guess I should also mentioned that I am not using the Universal Login page, but my own custom embedded page.

This is how I am logging users in:

auth0 = new auth0.WebAuth({
    clientID: 'xxxxx',
    domain: 'xxxxx.au.auth0.com',
    audience: 'https://xxxxxxx.au.auth0.com/api/v2/',
    responseType: 'token id_token',
    scope: 'openid',
    leeway: 60
});

Login(loginModel: LoginModel): Observable<TokenModel> {

    this.animationHelper.startLoading();

    return Observable.create((observer: Observer<TokenModel>) => {
        this.auth0.client.login({
            realm: 'xxxxxx-Development',
            username: loginModel.emailAddress,
            password: loginModel.password
            }, (err, authResult) => {
                if (err) {
                    observer.error(err.description);
                }
                else if (authResult && authResult.accessToken && authResult.idToken) {
                    let tokenModel = new TokenModel();
                    tokenModel.accessToken = authResult.accessToken;
                    tokenModel.expiresIn = authResult.expiresIn;
                    tokenModel.idToken = authResult.idToken;
                    tokenModel.tokenType = authResult.tokenType;

                    observer.next(tokenModel);
                }

                this.animationHelper.endLoading();
                
                observer.complete();
        });

    });
}

Please note that xxxx is a replacement for confident data

Does checkSession method expects a cookie or something? If so, is the login method creating this cookie? Thanks for your help

7

Ok, after a long investigation I have found this: JSDoc: Home
" * client.login(options, callback) : Authenticates a user with username and password in a realm using /oauth/token . This will not initialize a SSO session at Auth0, hence can not be used along with silent authentication."

As I have been using auth0.client.login() instead of auth0.login() for authentication, I was not creating the sso cookie required by checkSession.

Now, after testing the alternatives, including auth0.login(), they all do a full http reload on my application which is something that we dont want in our SPA. Is there a solution, a way of getting the required sso cookies without this full page reload (requestUri)?

8

Is this a limitation of Auth0 by any chance? Could someone clarify this?

9

Hey Walter, are you logging in via a Social Provider by any chance?

If you are using Auth0 Dev Keys and not your own for a social provider, then checkSession will always return with a “login_required”. Does that help?

2 Likes
10

No I am not.
I think I have provided a complete information of my scenario above. Please go through that to see if you can spot an issue? thank you

11

How can I get my jwt AND the sso cookies required for Silent Login / Refresh Token (auth0js checkSession() ) without doing a full page reload on my first login? Can someone assist?

12

As you noted, the client.login method won’t meet your requirements. The recommendation would be to make use of universal login as that will establish a SSO session. However, if you need to go with an embedded login approach you can consider the login method which does cross-origin authentication in a way that it could be possible to leverage a session for subsequent renewals.

However, have in mind that cross-origin authentication has some significant consideration attached to it in terms of browser configurations supported (see Cross-Origin Authentication).

13

How? I have been trying to find this for days. I have workmates already prototyping a solution with firebase and Active Directory. I am the only one insisting with Auth0.
How can we login and extend / refresh / renew the access token without having to login again and specially without having our Single Page Application to fully reload?
Can I have a solution with an example for this please.

14

I’m unsure if the sample application at (https://github.com/auth0-samples/auth0-angular-samples/tree/embedded-login/01-Embedded-Login) would match all those requirements, but it does show embedded login leveraging cross origin authentication. The use of cross origin authentication, if feasible to your scenario, would then allow renewing tokens in the background.

15

The example that you presented handles callbacks and read data from the url, meaning it requires a full page reload on every login (user manually entering credentials).
This defeats the purpose of a Single Page Application.
We are now in the final stages of migrating from Auth0 to Firebase Authentication. Although it provides less customization, it does what we need: manual login (user entering credentials) and token refresh.

Thanks for your help and if Auth) ever provides a full solution for Single Page Applications, please reply to this thread as I will be keeping my account here.

16

What you mention is correct that it requires a redirect, however, in general such interactive login should happen infrequently. In addition, this redirect completes automatically and the browser should be able to leverage a primed cache so that loading the application again has less overhead.

Upon this initial login the application should then be able to refresh tokens without any further redirects depending on browser configuration.

17

Thanks this is what I was missing! Maybe I skim read but I didn’t see something warning about this in the docs when setting up with React, I knew I hadn’t made my own oAuth app but expected the preconfigured one to work properly.

1 Like
18

A little late to this party, I apologize … really great discussion! Thanks @walterpalombini for facilitating. My question is, is it possible to do Silent (re)Authentication with a Social Provider?

I’ve just realized why I’m getting the login_required error when trying to call checkSession() as I’m logging in to my SPA with a Google Account. Is there a way to handle not automatically logging the user out every 2 hours when using a social provider?

1 Like
19

Going to answer my own question, but I would truly appreciate validation from someone at Auth0.

It appears that after I registered my Google Provider with a Client ID and a Client Secret. The checkSession() call began to work. I came across this kind of randomly looking at this documentation.

I assume that this is intended, but is what I’m doing/saying “correct?”

1 Like
20

Thank you for posting this; I just spent four hours trying to figure out why my session absolutely refused to stick. After reading your comment, I switched off the social providers and just went with email/password. And magically it works like you would expect! After hours of reading documentation forwards and backwards, reworking code in a thousand ways, it was because I was using logging into my SPA with my Google account; you may be onto something with the client ID & secret, but I’ll explore that later. I’m just happy to have my damn authentication lasting beyong a browser refresh.