Hi David,
SAML (Security Assertion Markup Language) is an XML-based standard for exchanging authentication and authorization data between an identity provider (IdP) 
such as Okta, and a service provider (SP) such as Box, Salesforce, G Suite, Workday, etc.

Both IdP and SP-initiated authentication flow rely upon assertions that are passed between the user’s browser and URLs that are specifically created to handle SAML traffic (known as endpoints). These assertions are in XML format and contain information that verifies who the identity provider is, who the 
user is, and whether the user should have access to the SP

1. The user (e.g. john@MyBusiness.com) navigates to the SP’s login page and begins to log in. Some SPs offer a link to "sign in using SSO" on the login page, whereas others can be configured to utilize SAML for all sign-on requests based upon the domain portion of the username (e.g. users@MyBusiness.com). SPs that utilize custom login pages (e.g. https://MyCompany.Dropbox.com) can often be configured to utilize SAML for ALL login attempts.
2. The SP generates a SAML request and redirects the user to the Okta Single Sign-On URL endpoint with the request embedded. This endpoint is unique for each application within each Okta tenant.
3. Once the user is redirected to Okta they’ll need to enter their Okta credentials, unless they had already authenticated into Okta in a previous session within the same browser. In either case, a successful authentication request will redirect the user back to the SP’s Assertion Consumer Service (ACS) URL with an embedded SAML response from Okta. At a minimum, the response will:
a)Indicate that it is indeed from Okta and hasn’t been altered, and contain a digital signature proving such. This signature will be verified by the SP using a public key from Okta that was previously uploaded to the SP as a certificate.
b)Indicate that the user has authenticated successfully into Okta
c)Indicate who the user is via the NameID, a standard attribute used in SAML assertions.
4. After the assertion is successfully parsed by the SP’s ACS, the user will then be sent to the SP’s default relay state, which is usually the same page they’d wind up if they’d simply logged into the SP with a username and password. As SPs such as G Suite and Office 365 host several different services, the default relay state will help dictate which specific service to send them to (for example, directly to Outlook Webmail instead of Office 365’s main landing page).

Please check the below link for more information:
https://support.okta.com/help/s/article/Beginner-s-Guide-to-SAML

I hope you find the above solution helpful. If it does, please mark as Best Answer to help others too.
Thanks,
Ajay Dubedi