# Launch app within an EHR system
You can use this API action to authorize and authenticate a single sign-on (SSO) request to launch apps within an EHR system.
Redox handles SSO requests with OAuth 2.0. We store the access tokens for you and automatically refresh the tokens as needed.
This API action allows you to quickly and efficiently integrate with a new connection’s system by using an existing configuration with minimal code changes.
> **SSO basics**
>
> If you want more high-level info, [learn about app launch via SSO](/basics/handling-app-launch-sso-from-ehr-systems).
## Use cases
This API action may be a good fit for your organization if you perform any of these use cases:
- Allow a provider or patient to access your app directly from their system.
- Enable SSO for you to make FHIR API requests to your connection’s system.
- Allow Redox to automatically refresh access tokens for your system.
## Supported systems
You can use this API action with the Redox FHIR API. For SSO, you can use SAML, SMART, or other SSO schemes. Redox is compatible with any OAuth or OpenID Connect provider. When using SMART, you must register your app with a provider that supports SMART.
Your connection must have their own FHIR API to launch apps from their system using a Redox launch URL.
## Things you need to know
How the SMART app launch works
This diagram gives you a visual idea of how SMART App Launch works with Redox:
*SMART app launch flow*
Shared security responsibilities between your app and Redox
Launching an app via Redox requires extra security measures. So, Redox sends SSO requests with a JSON Web Token (JWT) signed using HMAC with SH-256, or `HS256` ([learn about JWTs](https://en.wikipedia.org/wiki/JSON_Web_Token)). A secret is generated in the Redox dashboard on each SSO configuration. The JWT is sent in the `Authorization` header as a bearer token. Additionally, the JWT conforms to the OpenID Connect claims ([refer to openID Connect claim definitions](https://openid.net/specs/openid-connect-core-1_0.html#StandardClaims)).
What your app must do:
- Validate that the `Authorization` header JWT coming from Redox is correctly signed using the secret value set in the Redox dashboard.
- Validate claims in the Redox JWT:
- `iss` is the Source ID initiating the request.
- `aud` is the SSO Configuration ID receiving the request.
- `iat` must be in the past.
- `exp` must be in the future.
- Validate any other app-specific business logic you want to enforce using other claims.
- Securely craft a redirect URL, which means that (a) the redirect URL should only be valid to use once and (b) any tokens sent in the redirect URL should have sufficient entropy. Your app owns the security of the sessions.
- Expire the sessions as appropriate. Note that the JWT provides an expiration time, but this may need to be shortened based on your system policies. Also note that many EHR systems we’ve worked with don't support single logout.
What Redox does:
- Validate the incoming SSO launch request.
- In SAML, this means verifying the signature using a provided public key.
- In SMART/OpenID Connect, this means verifying that the URLs and `id_tokens` are signed appropriately and match the configuration in Redox.
- Maintain the security of the HMAC secret in the Redox dashboard and ensure it's generated securely.
Redirect best practices
1. When you send a `302` to Redox, we return whatever the particular EHR system needs. If they can handle redirects, we pass it along, but we find a way to do it if they don't. For example, if the EHR system expects content to be returned, we respond with `meta http-equiv=”refresh”`, a javascript redirect, and a link to the URL.
2. Don’t use relative URLs. You don’t know what URL the browser will be set to when your content is loaded. For example, it could be `about:blank` or the initial Redox URL. In either of those cases, relative URLs don't redirect to your content.
3. Set cookies after you redirect. Cookies are attached to the domain that they're set on, so if your content is inserted into a frame with `about:blank` and then you redirect to your URL, the cookie is inaccessible.
4. Avoid referencing `window.parent`, or `top` in JavaScript. Your system is either hosted in an iFrame or in a full-blown browser embedded into whatever platform the EHR system runs on. The safest path is to assume that you're on the top level.
Building the launch button
Your connection requires a launch button in their own system to trigger the SSO request to Redox. This button must be developed by your connection.
Building the UI
Redox facilitates the SSO request, but we don’t build a UI for launching and accessing your app. Part of using this API action requires that you develop and maintain the UI for your connection.
Creating a backup plan
Not every connection can support launching an app from their system. We recommend having a backup plan for launching your app to accommodate all of your connections, regardless of SSO capabilities. For example, you could make your app available with a URL that allows patients or providers to log in separately if SSO isn't available.
OAuth or OpenID Connect providers
After registering your app, you can check out these sandbox environments that work with Redox:
- [Cerner Code](https://code.cerner.com/)
- [Epic FHIR®](https://fhir.epic.com/)
Each vendor requires different information, but one required element you must include is this redirect `uri: https://launch.redoxengine.com/redirect`. This tells the authorization service that it's okay for Redox to handle the authorization and SSO request.
> **What's next? **
>
> Does this API action seem like a good fit for your unique workflow? Let your Technical Account Manager know! To start development, download the resource schema noted in the related action step. Then decide which data elements you need.
>
> If you’re new to Redox, [use the Quickstart guide](/quickstart-for-redox) to dive in. If you’re not engaged with our sales team yet, [talk to a Redoxer](https://redoxengine.com/forms/contact-us/) to get started.