Which strategy to use: “3rd party” cookie

[shainegordon]

I have an existing .NET API that handles authentication. Given a valid username and password, it produces an HttpOnly cookie.

This cookie is used to then authenticate subsequent API requests.

I want to continue to use this API from my Remix loader

Which strategy would I use? Or is this project not applicable to me?

I’m basically looking for a simple way to know the user is not authenticated (response 401 from a “get user details” endpoint), and redirect to login. This library seems to have nice hooks for that purpose.

[shainegordon]

Is this as simple as using the “FormStrategy” example, modified?

import { FormStrategy } from "remix-auth-form";

// The rest of the code above here...

authenticator.use(
  new FormStrategy(async ({ form, context }) => {
   
    // snipped from example 

    // And finally, you can find, or create, the user
    try {
        let user = await callGetUserProfileApi();
    } catch (err) {
        If (err.status == 401) {
            await callLoginApi(username, password); // this will create the cookie 
            // now refetch the user 
            user = await callGetUserProfileApi();
     }

    // And return the user as the Authenticator expects it
    return user;
  })
); `

[sergiodxa]

How do you do the login? Is the login form going to live inside Remix? Or will you send the user to the .NET app which will handle the login and set the cookie?

[shainegordon]

The login form will live in remix.

The API has a /api/login endpoint that accepts the username/password. This endpoint validated the username/password, creates a cookie, and returns a 204 NoContent

[shainegordon]

I’ve looked that the source, and it seems quite easy to create a new strategy.

If one of the existing ones work, I will look at contributing a new strategy - I actually just created one for for a nuxt auth library sidebase/nuxt-auth#495

[sergiodxa]

You could use the FormStrategy, and once you get the response with the Set-Cookie header, grab that cookie, parse it (with something like cookie-js) and return from the strategy whatever the .NET api set on the cookie.

Then when you make a request to your .NET api instead of sending an Authorization header you can send a Cookie (not Set-Cookie) header with the same name .NET expects and the value.

Ideally, you should be able to configure .NET to work as an actual API and don't rely on cookies, instead give you a token as the response of the /api/login endpoint and authenticate request using the Authorization header. But I don't know how to do that on .NET since I have never used it.

[shainegordon]

Yes, I can modify the API to use a token instead of a cookie. I’ll just need to ensure that it is still session based, as one of the business requirements is to be able to invalidate the session - something that works out the box with cookies

[sergiodxa]

If the token is stored in the DB, you can invalidate a session by deleting it from the DB (or marking it as invalid).

[shainegordon]

Once I understood how to use an external cookie in Remix - https://dev.to/2ezpz2plzme/authenticating-remix-cookie-sessions-with-django-cookie-sessions-36h9 - adopting remix-auth-form was trivial

// session.server.ts
const SESSION_SECRET = "A_SUPER_SECRET_VALUE"

export const API_COOKIE_NAME = ".AspNetCore.Identity.Application";

export const sessionStorage = createCookieSessionStorage({
    cookie: {
        name: 'sessionid',
        path: '/',
        secrets: [SESSION_SECRET],
        secure: process.env.NODE_ENV === 'production',
        // More cookie options could be added here, but we will be using the cookie options from the fetch responses later.
    },
})

// auth.server.ts
export let authenticator = new Authenticator<string>(sessionStorage);

function login(username: string, password: string) {
    return fetch("https://localhost:5001/auth/login", {
        method: "POST",
        headers: {
            "Content-Type": "application/json",
        },
        body: JSON.stringify({
            username,
            password,
        }),
    });
}

authenticator.use(
    new FormStrategy(async ({ form }) => {

        let username = form.get("username");
        let password = form.get("password");

        invariant(typeof username === "string", "username must be a string");
        invariant(username.length > 0, "username must not be empty");

        invariant(typeof password === "string", "password must be a string");
        invariant(password.length > 0, "password must not be empty");

        let response = await login(username, password);

        const setCookieHeader = response.headers.get("Set-Cookie");

        if (!setCookieHeader) {
            throw new Error('no Set-Cookie header')
        }

        const parsedResponseCookies = setCookie.parse(
            setCookie.splitCookiesString(setCookieHeader)
        );

        const sessionIdCookie = parsedResponseCookies.find(
            (cookie) => cookie.name === API_COOKIE_NAME
        );

        if (!sessionIdCookie) {
            throw new Error(`no ${API_COOKIE_NAME} cookie found`);
        }

        // Store the response's `sessionid` cookie into the headers.
        const { value } = sessionIdCookie;

        return value;

    }),
    // each strategy has a name and can be changed to use another one
    // same strategy multiple times, especially useful for the OAuth2 strategy.
    "user-pass"
);

// auth.server.ts
import { API_COOKIE_NAME } from "~/session.server";
import { authenticator } from "~/auth.server";

export async function fetchWithCookie(
    request: Request,
    input: RequestInfo | URL,
    init?: RequestInit
): Promise<Response> {
    let user = await authenticator.isAuthenticated(request, {
        failureRedirect: "/login",
    });

    const headers = {
        "Content-Type": "application/json",
        Cookie: `${API_COOKIE_NAME}=${user}`,
        ...init?.headers,
    };

    return await fetch(input, { ...init, headers });
}

[josevitormorais]

@shainegordon nice solution. 👏

I have same this problem, i was ready create a PR for suggestion, for example:

in the strategy of remix-auth, accept an option response headers, when have this option, concat at with Set-Cookie of the session commit;
because, many cookies can be returned from any server (BFF).

but, why it? I don't want to manually set the cookie header for every request, the browser does it for me;

snippet:

/**
 * Extra information from the Authenticator to the strategy
 */
export interface AuthenticateOptions {
  /**
   * The key of the session used to set the user data.
   */
  sessionKey: string;
  /**
   * In what key of the session the errors will be set.
   * @default "auth:error"
   */
  sessionErrorKey: string;
  /**
   * The key of the session used to set the strategy used to authenticate the
   * user.
   */
  sessionStrategyKey: string;
  /**
   * The name used to register the strategy
   */
  name: string;
  /**
   * To what URL redirect in case of a successful authentication.
   * If not defined, it will return the user data.
   */
  successRedirect?: string;
  /**
   * To what URL redirect in case of a failed authentication.
   * If not defined, it will return null
   */
  failureRedirect?: string;
  /**
   * Set if the strategy should throw an error instead of a Reponse in case of
   * a failed authentication.
   * @default true
   */
  throwOnError?: boolean;
  /**
   * The context object received by the loader or action.
   * This can be used by the strategy if needed.
   */
  context?: AppLoadContext;
    /**
   * Any type of header for response.
   */
  responseHeaders?: Headers;
}

  /**
   * Returns the user data or throw a redirect to the successRedirect.
   * @param user The user data to set in the session.
   * @param request The request to get the cookie out of.
   * @param sessionStorage The session storage to retrieve the session from.
   * @param options The strategy options.
   * @returns {Promise<User>} The user data.
   * @throws {Response} If the successRedirect is set, it will redirect to it.
   */
  protected async success(
    user: User,
    request: Request,
    sessionStorage: SessionStorage,
    options: AuthenticateOptions
  ): Promise<User> {
    // if a successRedirect is not set, we return the user
    if (!options.successRedirect) return user;

    let session = await sessionStorage.getSession(
      request.headers.get("Cookie")
    );

    // if we do have a successRedirect, we redirect to it and set the user
    // in the session sessionKey
    session.set(options.sessionKey, user);
    session.set(options.sessionStrategyKey, options.name ?? this.name);

    let headers = new ImmutableHeaders(options.responseHeaders ?? {}).set(
      "Set-Cookie",
      await sessionStorage.commitSession(session)
    )

    throw redirect(options.successRedirect, { headers });
  }

@sergiodxa this is trivial? or bad for base library?
thank you for this library, it's really great work.

[shainegordon]

If I understand your issue, assuming it is the same as mine, you really have no choice but to set the header on every call to fetch

Remember that your browser is calling remix server. It will 100% send the cookie automatically. But once you are on the server, you are now in "node land", and browser cookies no long exist.

This is why you need to extract the cookie from remix session, and set it as a request header.

On the initial auth, the same "problem" occurs. A node server is calling an auth API, which is returning Set-Cookie header. Set-Cookie is a browser trigger to create a cookie, hence why you need to read that header, set it on remix session, which remix will then return a response with a Set-Cookie, which the browser will then see, and treat as the cookie.

[josevitormorais]

Remember that your browser is calling remix server. It will 100% send the cookie automatically. But once you are on the server, you are now in "node land", and browser cookies no long exist.

this statement is not true, because you can access all headers and cookies from the remix request.headers (loaders and actions). then you can forward(i make it) to your backend server, if you have a backend besides remix(node) the remix in this case is a proxy.

On the initial auth, the same "problem" occurs. A node server is calling an auth API, which is returning Set-Cookie header. Set-Cookie is
a browser trigger to create a cookie, hence why you need to read that header, set it on remix session, which remix will then return a response with a Set-Cookie, which the browser will then see, and treat as the cookie.

i have an soluction similar to yours, when my authentication was based on jwt:

but on my use case (uploading files), i need calls from client side, wihout calls to remix server, then I changed the strategy for session cookies.

[josevitormorais]

Regarding my solution that I mentioned above, it doesn't make sense.
I looked deeper into the code, and the success method, doenst have access of the response data:

in this way, I changed my strategy, copying the source code of remix-auth-form, and overriding the success method, look at snippet:

import { Headers } from "@remix-run/node";
import { AppLoadContext, SessionStorage, redirect } from "@remix-run/server-runtime";
import { AuthenticateOptions, Strategy } from "remix-auth";

export interface FormStrategyVerifyParams {
    /**
     * A FormData object with the content of the form used to trigger the
     * authentication.
     *
     * Here you can read any input value using the FormData API.
     */
    form: FormData;
    /**
     * An object of arbitrary for route loaders and actions provided by the
     * server's `getLoadContext()` function.
     */
    context?: AppLoadContext;
}

export class FormStrategy<User> extends Strategy<
    User,
    FormStrategyVerifyParams
> {
    name = "form";

    async authenticate(
        request: Request,
        sessionStorage: SessionStorage,
        options: AuthenticateOptions
    ): Promise<User> {
        let form = await this.readFormData(request, options);

        try {
            let user = await this.verify({ form, context: options.context });
            return this.success(user, request, sessionStorage, options);
        } catch (error) {
            if (error instanceof Error) {
                return await this.failure(
                    error.message,
                    request,
                    sessionStorage,
                    options,
                    error
                );
            }

            if (typeof error === "string") {
                return await this.failure(
                    error,
                    request,
                    sessionStorage,
                    options,
                    new Error(error)
                );
            }

            return await this.failure(
                "Unknown error",
                request,
                sessionStorage,
                options,
                new Error(JSON.stringify(error, null, 2))
            );
        }
    }

    /**
    * Returns the user data or throw a redirect to the successRedirect.
    * @param user The user data to set in the session.
    * @param request The request to get the cookie out of.
    * @param sessionStorage The session storage to retrieve the session from.
    * @param options The strategy options.
    * @returns {Promise<User>} The user data.
    * @throws {Response} If the successRedirect is set, it will redirect to it.
    */
    protected async success(
        user: User,
        request: Request,
        sessionStorage: SessionStorage,
        options: AuthenticateOptions
    ): Promise<User> {
        // if a successRedirect is not set, we return the user
        if (!options.successRedirect) return user;

        let session = await sessionStorage.getSession(
            request.headers.get("Cookie")
        );

        // if we do have a successRedirect, we redirect to it and set the user
        // in the session sessionKey
        session.set(options.sessionKey, user);
        session.set(options.sessionStrategyKey, options.name ?? this.name);

        let responseHeaders = new Headers((user as any)?.headers);
        responseHeaders.delete('connection')

        throw redirect(options.successRedirect, {
            headers: [
                ...Array.from(responseHeaders.entries()),
                ["Set-Cookie", await sessionStorage.commitSession(session)],
                ["Set-Cookie", responseHeaders.get('Set-Cookie') || ''],
            ],
        });
    }

    private async readFormData(request: Request, options: AuthenticateOptions) {
        if (options.context?.formData instanceof FormData) {
            return options.context.formData;
        }

        return await request.formData();
    }
}

[josevitormorais]

on my authenticator, have this:

[shainegordon]

For completeness, my .NET API also supports Google, Facebook, etc login, which is a different flow. With this flow, there is no API response, because of the redirects involved, so here, when you get back to the frontend, there is no Reponse Set-Cookie header, but rather a Request Cookie header.

So I implemented another Strategy to handle that, which is very simple, and basically is a copy/paste of remix-auth-form, with some things deleted, and a different set of 'props`

// remix-auth-oauth-callback.ts
import type { AppLoadContext, Request, SessionStorage } from "@remix-run/node";
import type { AuthenticateOptions } from "remix-auth";
import { Strategy } from "remix-auth";

interface OauthCallbackStrategyVerifyParams {
    request: Request;
    context?: AppLoadContext;
}

export class OauthCallbackStrategy<User> extends Strategy<
    User,
    OauthCallbackStrategyVerifyParams
> {
    name = "oauth-callback";

    async authenticate(
        request: Request,
        sessionStorage: SessionStorage,
        options: AuthenticateOptions
    ): Promise<User> {
        try {
            let user = await this.verify({ request, context: options.context });
            return this.success(user, request, sessionStorage, options);
        } catch (error) {
            if (error instanceof Error) {
                return await this.failure(
                    error.message,
                    request,
                    sessionStorage,
                    options,
                    error
                );
            }

            if (typeof error === "string") {
                return await this.failure(
                    error,
                    request,
                    sessionStorage,
                    options,
                    new Error(error)
                );
            }

            return await this.failure(
                "Unknown error",
                request,
                sessionStorage,
                options,
                new Error(JSON.stringify(error, null, 2))
            );
        }
    }
}

//auth.server.ts
function getApiCookie(headers: Headers) {
    let cookieHeader = headers.get("Set-Cookie");

    if (!cookieHeader) {
        cookieHeader = headers.get("Cookie");
    }

    if (!cookieHeader) {
        throw new Error("no Cookie or Set-Cookie header");
    }

    const parsedResponseCookies = setCookie.parse(
        setCookie.splitCookiesString(cookieHeader)
    );

    const apiCookie = parsedResponseCookies.find(
        (cookie) => cookie.name === API_COOKIE_NAME
    );

    if (!apiCookie) {
        throw new Error(`no ${API_COOKIE_NAME} cookie found`);
    }

    return apiCookie;
}

authenticator
    .use(
        new FormStrategy(async ({ form }) => {
            let username = form.get("username");
            let password = form.get("password");

            invariant(
                typeof username === "string",
                "username must be a string"
            );
            invariant(username.length > 0, "username must not be empty");

            invariant(
                typeof password === "string",
                "password must be a string"
            );
            invariant(password.length > 0, "password must not be empty");

            let response = await login(username, password);

            const apiCookie = getApiCookie(response.headers);

            const { value } = apiCookie;

            return value;
        }),
        "user-pass"
    )
    .use(
        new OauthCallbackStrategy(async ({ request, context }) => {
            const apiCookie = getApiCookie(request.headers);

            const { value } = apiCookie;

            return value;
        }),
        "oauth-callback"
    );

// routes/login.tsx

// snipped
            {oAuthProviders.map((provider) => (
                <form
                    key={provider}
                    action={`${apiBaseUrl}/auth/oauth?provider=${provider}&returnUrl=http://localhost:3000/oauth-callback`}
                    method="post"
                >
                    <Button type="submit">Login with {provider}</Button>
                </form>
            ))}

// routes/oauth-callback
export async function loader({ request }: LoaderArgs) {
    // If the user is already authenticated redirect to /dashboard directly
    await authenticator.isAuthenticated(request, {
        successRedirect: "/me",
    });

    return await authenticator.authenticate("oauth-callback", request, {
        successRedirect: "/me",
        failureRedirect: "/login",
    });
}

Reading this again, I should probably change that strategy name, because really it is probably rather a Request Validation Strategy

There is probably a more elegant way to do this, but we wont be moving away from our API + Auth server, and OAuth works like it works, but happy to hear suggestions