@makerx/express-msal
v1.3.0
Published
Simple server-side cookie-session based Azure AD authentication for Express.js apps.
Downloads
409
Keywords
Readme
Express MSAL
Simple server-side cookie-session based Azure AD authentication for Express.js apps.
What does this do?
This library wraps @azure/msal-node to provide a simple way to run interactive authentication on Express JS hosted UIs (web pages) that need to call APIs using Bearer token authentication, without writing and deploying client-side MSAL code.
As an example use case, we host GraphQL Playground or Apollo Sandbox and Voyager UIs alongside our GraphQL APIs from server-side middleware. This package allows us to add authentication across all those UIs without building, packaging and deploying custom UI code.
For Bearer token authentication, see @makerxstudio/express-bearer.
Usage
npm install @azure/msal-node express cookie-session @makerxstudio/express-msal
import { ConfidentialClientApplication } from '@azure/msal-node'
import { AuthConfig, pkceAuthenticationMiddleware, copySessionJwtToBearerHeader } from '@makerxstudio/express-msal'
import cookieSession from 'cookie-session'
const app = express()
app.use(cookieSession(cookieSessionOptions))
const msalApp = new ConfidentialClientApplication(msalConfig)
const authConfig: AuthConfig = {
app,
msalApp,
scopes: ['profile', 'api://my-api/.default'],
}
// trigger pkce auth on GET requests (iteractive users accessing UIs)
app.get('*', pkceAuthenticationMiddleware(authConfig))
// set a Bearer {token} auth header on POST request to '/graphql'
app.post('/graphql', copySessionJwtToBearerHeader)
pkceAuthenticationMiddleware
starts the PKCE auth flow (redirect) when there is no session, creates a cookie-session containing an accessToken.copySessionJwtToBearerHeader
: takes the accessToken from the session cookie and adds a Bearer {token} header onto the request, useful for supporting API access from your session-based auth (will not overwrite existing authorization header on the request).
Is this secure?
Auth configuration security
We recommend you use the Web
platform auth configuration in Azure and use ConfidentialClientApplication
(which requires a client secret). Using this auth configuration which requires a client secret prevents your auth client ID being used outside of your controlled server-side application.
Session security
We only use cookie-session with this library, along with secure-as-possible cookie configuration.
The logic here is that access tokens are already persisted in browser storage and are freely available in the browser, however it's definitely possible to configure an insecure session cookie that does not restrict access to the cookie and access token adequately.
We strongly recommend configuring your cookie-session options carefully, applying the most restrictive policy, setting path
, domain
, sameSite
, secure
, httpOnly
etc.
const cookieSessionOptions = {
name: '<session-name>',
maxAge: 1000 * 60 * 60,
sameSite: 'strict',
secure: true,
httpOnly: true,
}
app.use(cookieSession(cookieSessionOptions))
Config
AuthConfig
:
| Option | Description |
| --------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------- |
| app
| The Express JS app on which the auth reply handler is set up (see authReplyRoute
). |
| msalClient
| The @azure/msal-node
ConfidentialClientApplication
instance. |
| scopes
| The scopes to use to aquire the accessToken. |
| authReplyRoute
| The route on which the auth completion handler is be set up, which must be configured in the Azure App Registration, default: /auth
. |
| augmentSession
| Optional function to add additional info to the session from the msal AuthenticationResult
. |
| logger
| Optional logger implementation to log token validation errors, handler setup info entry etc. |
| authorizationUrlRequestOverride
| Optional per request override of the authorisation URL request configuration, allows for things like dynamic authority for multi-tenanted apps, etc. |
Detailed usage examples
// set up cookie-session
const cookieSessionOptions = {
name: '<session-name>',
maxAge: 1000 * 60 * 60, // match session lifetime to the access token
sameSite: 'strict',
secure: true,
httpOnly: true,
}
app.use(cookieSession(cookieSessionOptions))
// set up msal client
const msalApp = new ConfidentialClientApplication({
auth: {
clientId: '<client-ID>',
clientSecret: '<client-secret>'
authority: 'https://login.microsoftonline.com/<tenant-ID>',
},
})
// configure all config options
const authConfig: AuthConfig = {
app,
msalApp,
scopes: ['profile', 'api://my-api/.default'],
// specify non-default reply url
replyUrl: '/auth-callback',
// add some additional info to the session from the msal `AuthenticationResult`
augmentSession: (response) => {
return { username: response.account?.username }
},
// specify a logger
logger,
// specify an authority override
authorizationUrlRequestOverride: (req) => ({authority: authorityLookup[req.host]})
}
// use pkce auth on everything apart from ./api*
app.use(/^\/(?!api).*/, pkceAuthenticationMiddleware(authConfig))
// set a Bearer {token} auth header on request to '/api*
app.use('/api*', copySessionJwtToBearerHeader)
// add a logout endpoint for GET requests to /logout
app.get('/logout', logout)
// return the currently logger in user's username from GET requests to /user
app.get('/user', (req, res) => {
if (!isAuthenticatedSession(req.session)) return res.status(400).send('Not logged in').end()
res.send(req.session.username).end()
})
Logging
Set the logger implementation to an object that fulfills the Logger
definition:
type Logger = {
error(message: string, ...optionalParams: unknown[]): void
warn(message: string, ...optionalParams: unknown[]): void
info(message: string, ...optionalParams: unknown[]): void
verbose(message: string, ...optionalParams: unknown[]): void
debug(message: string, ...optionalParams: unknown[]): void
}
Note: this type is compatible with winston loggers.
The following example uses console logging:
const logger: Logger = {
error: (message: string, ...params: unknown[]) => console.error
warn: (message: string, ...params: unknown[]) => console.warn
info: (message: string, ...params: unknown[]) => console.info
verbose: (message: string, ...params: unknown[]) => console.trace
debug: (message: string, ...params: unknown[]) => console.debug
}
const pkceAuthConfig: AuthConfig = {
/* other config */
logger,
}
@azure/msal-node
Use the MSAL system loggerOptions config to control logging from the @azure/msal package:
const config: Partial<Configuration> = {
system: {
loggerOptions: {
loggerCallback(loglevel: LogLevel, message: string, containsPii: boolean) {
console.log(message)
},
piiLoggingEnabled: false,
logLevel: LogLevel.Verbose,
},
},
}
To assist supplying a log function to MSAL, this module exports toNpmLogLevel
which maps MSAL LogLevel
values to npm log level labels, making it easy to integrate a winston Logger
instance:
const msalLoggerConfig: Partial<Configuration> = {
system: {
loggerOptions: {
loggerCallback: (level, message) => logger.log(toNpmLogLevel(level), message),
},
},
}