Source of diagrams
The goal of this document is to explain the various possibilities of authenticating a web service using the CAS protocol.

Technical possibilites

To authentify a web service from a browser:

PossibilitiesConstraints
redirect own the page url, may loose user interactions
window.open + postMessage user click
JSONPCAS TGC, same domain
hidden iframeCAS TGC, same domain

Diagrams

To simplify the diagrams, the client is in the middle, and only one arrow is used for redirects.

Consequence : the server-to-server requests are missing (serviceValidate from api/app to cas)

Well-known cases

Same session for HTML and API

The simplest solution is to protect SPA HTML pages with the same session cookie used to protect API.
Session timeout is handled as in traditional Web: user starts again at current page.

When single page application starts

Many applications (eg: spring-security) uses the "login_then" technic.

The "implicit grant" solution is mimicking OAuth2 "implicit grant" which passes the token as a fragment identifier. Note that it breaks CAS back channel Single Logout.
NB: prior to CAS 3.4.4 it was possible to do it, but getting the ticket in the query part is ok.

On session timeout

Prompt the user to relog, and use window.open + postMessage on click:

Hidden iframe

The hidden iframe can be used at startup, at session timeout. But it needs a valid CAS TGC, and has some cookies restriction.

JSONP

Important: do not use JSONP to return a bearer token, it would open CSRF issues.

You can use JSONP + cookies for readonly APIs, but you will not be protected by CSRF information leakage.