I'm working on an SPA which depends on an instance of Identity Server for authenticating users. I need a solution that manages my tokens locally, but Duende (the owners of Identity Server) lean towards a Backend For Frontend (BFF) pattern over Javascript libraries. This isn't going to work for us. Since the original oidc-client that was written by the authors of Identity Server is no longer maintained I've been looking at Javascript alternatives. The most likely candidate would seem to be Microsoft's MSAL.js which is built for Azure AD, but supposedly supports OIDC standards.
From what I can tell, MSAL.js forces you down an offline_access path using refresh tokens to renew security tokens. Even if I don't expressly require an offline_access scope the library appends one anyway! But my use case doesn't require refresh tokens. Instead I want my client to keep the session on the identity provider fresh using OIDC session mamnagement standards (via the check_session_iframe endpoint exposed by the provider's well-known JSON).
I have found that if I ignore the offline_access scope requested by the MSAL.js library so my identity provider only issues and ID token and an access token then MSAL continues to work just fine. It even has an ssoSilent option for explicitly renewing the tokens via a connect/authorize request in a hidden iframe. But as far as I can tell I can't have the library keeping that session fresh via an iframe like the old oidc-client used to.
So given that session management is part of the OIDC specification, and MSAL is supposed to be an OIDC-compliant library, am I missing something here?
Unfortunately, at this time MSAL.js does not have an API that integrates with the checksession endpoint. If you would like to see this added, you are welcome to open a PR on our Github.
Related
I need to implement a system where the frontend is a pure SPA made with react (by pure I mean it is only hosted as a bunch of static files) and a nodejs REST API made with express. I can not use any 3rd party authentication providers like Auth0, etc. so everything must work locally.
The app must have authentication and it must be more or less up to modern standards. I am looking to implement PKCE flow with short-lived JWT auth tokens and long-lived refresh tokens.
There is one thing I am confused about. Every guide on PKCE flow always mentions redirects from one URL to another during the auth flow. In my setup, however, redirects are highly unwelcome.
I want to check and find out whether it is OK to implement PKCE flow using pure XHR requests to communicate between the SPA and API. Is it appropriate to do so? What major risks are there compared to a setup with redirects?
EDIT: to make this question more specific, what should be the PKCE authentication flow if you can only use SPA and XHR (and must avoid redirects)?
There is one thing I am confused about. Every guide on PKCE flow always mentions redirects from one URL to another during the auth flow. In my setup, however, redirects are highly unwelcome.
The whole point with OAuth 2.0 is the delegation (redirect) to the ID Provider, such that the user always send his password to the ID Provider instead of sending the password to each application. So you will always need to redirect the user to sign in - but hopefully the user is already signed in, so he immediately becomes redirected back to your app. There are techniques to check if the user is signed-in using XHR, that can be used until he need to sign in.
what should be the PKCE authentication flow if you can only use SPA and XHR (and must avoid redirects)?
In the Authorization Code flow, the client typically does two request to the ID provider. The request to authorization endpoint typically is done through a redirect (e.g. in case the user need to authenticate), but the second request, to token endpoint can typically be done in the background using XHR or fetch using appropriate CORS configurations.
We are developing an application that uses a React front end website hosted on AWS using Amplify. This communicates with a .NET Core 3.1 Web API running on EC2 / Elastic Beanstalk. Cognito is used for user authentication with the Web API configured to use JWT tokens.
It works OK, but we have noticed that the Cognito provider stores the JWT access token in the browser local storage. This is what we see using F12 in Chrome and inspecting local storage.
From what we have read, storing access tokens in local storage is not advised as it makes the application susceptible to XSS attacks. Strange then, that the Cognito identity provider chooses to store sensitive information here.
If this approach is not considered safe, can the provider be configured to store this information elsewhere, such as cookies?
Alternatively, as we control both front and back ends, is there an alternative method that can be used to secure the API that does not involve tokens? Obviously the API needs to know which user is logged on to the web application in order to perform authorization checks. [Note authorization in the application is record level and defined in database tables, so it goes beyond simple user profile attributes.]
Many thanks in advance for your advice.
Doug
Security is a spectrum not a feature so it really depends on your appetite for risk vs effort. Amplify is not a particularly nice codebase, it has 500+ issues and if you look at the code you might be fairly shocked at the quality of it.
If you are using Hosted-UI then you can write code to manage the tokens yourself rather than using amplify, although you will need to learn a bit about OAuth grants and OIDC.
Be aware that the Hosted UI lacks a huge amount of features, so if you are going to use it make sure you are happy with it. Off the top of my head
no silent refresh capability in the hosted UI, so no safe way to store the refresh token.
no support for custom auth flow in the hosted UI
no passwordless support in the hosted UI
no ability to pre-populate a field in the hosted UI (e.g. username)
no ability to customise the plethora of obscure error messages in the custom UI
fixed now, but for years the email addresses were case sensitive!
An alternative is also to just use the AWS SDK to get tokens directly using cognito-idp but this also has a bunch of issues:
no code/PKCE/nonce capability so insecure in a mobile authsession
no ability to set oauth scopes, so can't use them
consequently not possible to use for OIDC
the SRP implementation is bananas and so far off spec
if you make device registration mandatory, it will deliver a working access tokens before the device is registered! (allows invisible devices for malicious logins)
We were using auth0 which was leagues ahead but we had to move to Cognito because of SMS OTP cost (min $25k per year at auth0).
I have been using AWS for over a decade now, Cognito is by far the worst service I have used, and I have used a lot! If you can avoid it, do so.
To answer the original question, yeah it's insecure. The best you can probably do is keep them in memory. If you wanted to you could probably put the hosted UI behind a cloudfront and use an lambda#edge to transform the token into a cookie instead. This has now opened you up to CSRF attacks though.
answering the original question: no, it is not safe at all.
Storing refreshtoken in any local storage accessable to any local app/script is not secure. So, the best way would be to store the refreshoten (and also the access token) in an httponly cookie or even better to store a one-time session token in httponly secure cookie could be used to get new access and refresh cookies - similarly as it is made by cognito hosted ui with XSRF-TOKEN.
See below how I would solve (and plan to solve) this issue:
Some background:
Due to GDPR regulations I think I can not use the cognito hosted ui - I have to make sure users read and accept the general terms and conditions (giving clear and auditable consent) and can review and accept cookie policies as well before they type in any user data for sign up. Nevertheless the built in hosted ui design is quite outdated and unflexible. I have an SPA website where I want to manage users, secure endpoints, etc.
So I have the following idea which is still not super secure but I think it is more secure one if you want to use js and ampify sdk and which also might answer your question:
I'll use amplify javascript sdk to let users sign up, change psw and log in (get tokenid, access token and refresh token), will make my own "hosted ui". I'll store the access token in memory only (not in local cookies and not in localstorage for sure). Access token will be used in header (bearer) to access apiGW endpoints. Access tokens will have very short expire dates. (I'd also use httponly secure cookies sent back by the apigw, as well as in the body.., then compare at BE side..)
And here comes the trick: I'd cut the refresh token into two. (Don't forget it is just a string.) I'd store the first part of the string in a local cookie (javascript can read it, if browser is closed and opened again it will be still there) and will send the other half of the refresh token to an apiGW endpoint (accessable without authentication) which will store it in a dynamoDB table (with TTL) and will send back an httponly secure cookie to the browser with a randomly generated "storagetoken" in it (which will be a key in dynamodb). There will be another unauthenticated apigw endpoint which will be called by the client whenever the client needs the full refresh token. Calling this endpoint the browser will send in the httponly secure cookie as well (same domain), so the backend will get it. As it is issued by the BE and available only in the given browser it can not be stolen so the backend will send back the stored half refreshtoken. The other half part of refreshtoken is stored in a simple cookie in the browser.
If the browser is closed and opened again client checks if there is any valid accesstoken and if not it checks if there is a half refeshtoken stored as cookie. Then ask the other part of refreshtoken assuming there is a httponlycookie also stored and it will get back the other part of the refreshtoken from the BE. In case of success the client tries to use the full refreshtoken to renew/get access token from cognito, in case of failure it will pop up the login screen.
Whenever refreshtoken is not in use it is deleted from the memory.
I know this is still not supersecure but might be a better solution than storing refresh token in localstorage.
Alternatively, as we control both front and back ends, is there an alternative method that can be used to secure the API that does not involve tokens?
I don't know anything of Amplify but in AWS Cognito what you describe is the Implicit grant OAuth flow. In AWS Cognito it is possible to use Authorization code grant where you instead of the token get a code which you in the backend can exchange for a user pool token.
https://docs.aws.amazon.com/cognito/latest/developerguide/cognito-user-pools-configuring-app-integration.html
I have my own identity authority set up using the Identity Server.
I'm running a native windows application and currently I'm using IdentityModel's OidcClient library to connect on the authority and obtain the token.
I want to add support for Azure AD and since I haven't been able to set-up the application on the Azure AD to use HybridWithProofKey flow, and found this MSAL I've decided to give it a shot.
In MSAL there is a PublicClientApplication class with accepts the string authority in its constructor (source)
When passing my URL in this constructor I imagined it would use the discovery service and found the correct endpoints and to its job. But to my suprise this dont work.
I get following error message:
AADSTS50049: Unknown or invalid instance.
Search on github MSAL for AADSTS50049 returned zero results. I've cloned the project and started with debugging.
I've figured out that the request is sent to my authority url but instead there is a GET request on the
GET https://login.microsoftonline.com/common/discovery/instance?api-version=1.0&authorization_endpoint=https%3A%2F%2Fmyidentityserverhostname%2Fidentityserver%2Foauth2%2Fv2.0%2Fauthorize HTTP/1.1
This request is done in this source and it returns the error above.
So, is MSAL intended to use with non azure authorities?
No. It's a proprietary client library for their proprietary backend.
Yes it can,
You need to use the Azure B2C library, it can be configured with other identity provideer, like facebook, google, linked in etc.
There is also an option to utilise a custom IDP, if it conforms to openId
See here.
https://go.microsoft.com/fwlink/?linkid=854174
Using MSAL.NET with a non-MS OpenID Connect provider is unnecessary, as Microsoft.AspNetCore.Identity provides sufficient support for social logins and other OIDC providers.
Also vendors of custom OpenID Connect servers provide own extensions (see IdentityServer docs and OpenIdDict samples).
As per this official example, MSAL is not required if you're only signing users in. They claim:
MSAL is used for fetching access for accessing protected APIs
BTW, if you're interested in MSAL.JS, then it's a completely different story – https://stackoverflow.com/a/73618966/968003.
I'm tried to build a new rich application and i'm having some problems designing the authentication process.
I've only two requirements :
An API needs to be available
An ADFS needs to be used to authentication
My first thoughts was to build the API and to use Angular.js for the frontend. However, I can't see how the authentication should work.
My API needs to be available though scripts. As far as I saw, the ADFS authentication always display t the webpage for the authentication process.
API are usually secured with OAuth2. We used an client id and a client secret to generate a token. But I can't have this behavior with an ADFS.
The only solution I see is to provide two authentications behavior with my application. One with the ADFS for the web access and in the web interface, add a possibility to generate a client id and a client secret associated with an user account that could be used for the API to the headless authentication.
Someone has already faced this kind of scenario?
Thanks a lot!
I assume the 'ADFS needs to be used for authentication' really means 'users should be able to use their Active Directory domain credentials to authenticate'.
If that is the case, you should take a look at Thinktecture IdentityServer. It's an OAuth2 authorization server that you can use with a Active Directory identity provider.
P.S. ADFS 3.0 that comes with Windows 2012R2 only supports the authorization code grant, which is not suitable for JavaScript apps.
I am building a cross-platform mobile app that interacts with a RESTful API, and I want to use OpenID Connect to authenticate my users. I will be building my own OpenID Connect provider server.
OpenID.net claims that:
OpenID Connect allows for clients of all types, including browser-based JavaScript and native mobile apps, to launch sign-in flows and receive verifiable assertions about the identity of signed-in users.
However, I can't find any documentation explaining how to actually authenticate for a mobile app client.
This StackExchange answer makes it clear that OpenID Connect does not support the "resource owner password-based grant" flow or the "client credentials" flow.
That just leaves the "authorization code" flow (normally used by server-side apps) and the "implicit grant" flow (normally used by client-side apps). Both of these seem to rely on redirecting the user to the provider's authorisation endpoint, and having the provider redirect back to the client URL. I don't see how this can apply to a mobile app.
Can anyone explain to me (or even better, point me at a tutorial or some example code) which explains how to do this?
Update
To clarify: OpenID Connect relies on the client redirecting the user to the Authorization Endpoint, and then the provider redirecting the user back to the client. In the case where the client isn't a web app, how can this work?
Mobile apps, at least on iOS and Android, can register custom URL schemes so that a redirect from a browser can send the user back to your app along with some query parameters.
So, you can use these flows in a native mobile app, but it involves sending the user to a web browser (either an external browser app or a web view built into your application) in order for them to authenticate with the OP.
A complete article presenting how to implement the "Authorization Code Grant" flow securely on a native mobile app is available here : Building an OpenID Connect flow for mobile. It is based on latest IETF OAuth 2.0 Security Best Current Practice.
Please also note that the use of the "Implicit Grant" flow is now highly discouraged.
I think that the Hybrid flow from the OpenID Connect spec is probably the one which you want to use. OpenID Connect Core Spec.
This does rely upon having a configured return URI, but as James says you would use a custom URI scheme to enable the mobile OS to redirect after login to your own app. Your app would then have an access code which it can use to obtain access tokens as needed (assuming that you are using Oauth2 to protect your back-end API services which the mobile app uses).
There is a vulnerability which would allow a malicious app to hijack your URI scheme and grab the tokens, There is a draft spec to overcome that Proof Key for Code Exchange by OAuth Public Clients which is worth considering implementing.
Using an app scheme URL is the correct answer as noted above. I wanted to add additional clarification since some responses above include links to an article that makes incomplete assertions about a compliant SSO design, and make it unnecessarily complicated for a simple SSO use case. I think google's model is secure and so I might model OIDC interactions with a homegrown IDP after how theirs works.
https://medium.com/klaxit-techblog/openid-connect-for-mobile-apps-fcce3ec3472
The design in this article linked above, as depicted in the diagram on the article, does not work for google's oAuth/OIDC implementation on Android. There are two reasons for this:
Google will not vend any client_secret for an oAuth client that is typed "Android"
Suppose I switch to "Web" application which does have a secret: Google will not allow a redirect_uri other than 'http' or 'https' for an oAuth client that is typed "Web"
Instead, google officially recommends letting the typical mobile flow (and you should also be using PKCE) drop an ID Token on the client, who can then exchange it for a session with the App server:
https://developers.google.com/identity/sign-in/android/backend-auth
This is secure because your IDP should be signing the JWT ID Token with a private key so it can be validated by your system's apps/services and used to assert validated (unexpired) identity intended for a particular OIDC client & audience.
** Do not pass ID Token as authorization on every request, but rather exchange it once with your backend for a secure session context as managed by your application.
Check out MITREid project on github:
MITREid Connect
This project contains an OpenID Connect reference implementation in
Java on the Spring platform, including a functioning server library,
deployable server package, client (RP) library, and general utility
libraries. The server can be used as an OpenID Connect Identity
Provider as well as a general-purpose OAuth 2.0 Authorization Server.