There are lot of terms like RSA, SHA-256, JWT, OAuth, OpenID Connect, SSO, TLS, and HTTPS. At first they seemed like a collection of unrelated technologies. In fact, they sit at different layers and solve different problems. The easiest way to understand them is to start with the cryptographic building blocks.
RSA is a public/private-key cryptographic algorithm. A private key is kept secret, while the corresponding public key can be shared. One important use of RSA is digital signatures: the private key signs information, and anyone with the public key can verify the signature.
SHA-256 is different. It is a cryptographic hash function. It takes arbitrary data and produces a fixed-size 256-bit fingerprint. Unlike encryption, hashing is not designed to be reversed. The purpose is to produce a fingerprint that can be used to detect changes or as part of a digital signature.
RS256 essentially means RSA combined with SHA-256 for digital signatures. The data is hashed with SHA-256, and RSA is used to create the signature with a private key. The receiver can then use the corresponding public key to verify it. These cryptographic building blocks are then used by higher-level authentication systems.
A JWT, or JSON Web Token, is a token format. It is simply a standardized way of representing information that one system wants to pass to another. A JWT commonly contains claims such as the user’s identity, the issuer, and an expiration time.
A typical JWT looks like: header.payload.signature
The JWT can be signed using RS256. In that case, the Identity Provider creates the JWT and signs it with its private key. The application receiving the JWT uses the Identity Provider’s public key to verify that the token really came from the expected issuer and has not been modified.
This brings us to SSO, or Single Sign-On. In an enterprise environment, the application usually does not want to maintain its own username and password system. Instead, it delegates identity to an Identity Provider, such as Microsoft Entra ID, Okta, or Ping. The flow is:
User │ ↓Company Application │ │ "Authenticate this user" ↓Identity Provider │ │ authenticate user │ issue token ↓JWT │ ↓Company Application │ │ verify signature ↓Authenticated user
The protocols behind this are OAuth 2.0 and OpenID Connect. OAuth 2.0 is primarily an authorization framework. It answers questions such as: what application is allowed to access what resource on behalf of a user? OpenID Connect, or OIDC, adds an identity layer on top of OAuth 2.0. It allows an application to establish who the user is.
There is still another layer underneath all of this: TLS. When the browser communicates with the application or the Identity Provider, the authentication messages and tokens have to travel across the network. TLS provides the secure communication channel.
Application │ │ HTTP ↓ TLS ↓ TCP ↓ IP
TLS itself uses several cryptographic mechanisms. RSA was historically used in TLS for key exchange, but modern TLS 1.3 normally uses ECDHE, or Elliptic Curve Diffie-Hellman Ephemeral, to establish a shared secret.
Once that shared secret has been established, TLS uses efficient symmetric encryption to protect the actual data flowing between the browser and server. Common choices include AES-GCM and ChaCha20-Poly1305.
This is an important distinction because RSA, ECDHE, and ChaCha20 do different jobs:
RSA / ECDSA → digital signatures and authenticationECDHE → establish a shared session keyAES-GCM / ChaCha20-Poly1305 → efficiently encrypt the actual communicationSHA-256 → cryptographic hashing
So when I log into an enterprise application, several layers may be working together at the same time:
Enterprise SSO
│
OAuth 2.0 / OIDC
│
JWT
│
RS256
/ \
RSA SHA-256
│
↓
TLS
│
HTTP/HTTPS
│
TCP
│
IP
TCP/IP moves the data across the network. TLS protects the communication. OIDC establishes the user's identity. OAuth 2.0 handles authorization. JWT provides a token format for carrying claims. RS256 can provide the token's digital signature. RSA provides the public/private-key mechanism, while SHA-256 provides the cryptographic hash.
Once these layers are separated, the collection of acronyms becomes much easier to understand. They are not competing technologies. They are pieces of one system, with each layer solving a different problem.
Lastly, note RSA encryption versus RSA signatures are different:
ENCRYPTION:public key ──► encrypt ──► private key ──► decryptSIGNATURE:private key ──► sign ──► public key ──► verify