Hi @daniel.l.christensen, welcome to the Auth0 community!
Thank you for reading my article and submitting your doubts.
Let me summarize your first question: “What role does the ID token play in a SPA-based scenario?”
It has the same role as in a regular web application: it states that the user has been authenticated.
If requested, you can have the user’s data in the token.
Please, don’t confuse receiving an ID token with creating a session. As the application developer, you have the responsibility to create your own application session (cookie-based or other). The ID token is simply the result of the authentication process, nothing more.
I described the regular web application scenario in the article for simplicity, but the role of the ID token is always the same.
Your second question: “Is an OAuth2 access token different than an OIDC access token or is this just a matter of different settings for the expiration?”
OIDC access tokens are OAuth2 access tokens. OIDC is built on top of OAuth2. You can consider it a sort of OAuth2 extension.
The length of your access token lifetime depends on its potential exposure to the risk of being stolen.
In a scenario where a backend application (e.g., LinkedIn) calls another backend application (e.g., Twitter API) on behalf of the user, the risk of access token theft is lower than in a scenario where a public client (e.g., a SPA or a mobile app) calls an API.
While you have control over the environment where a backend application runs, you have no control over the environment where a public client runs. So, to minimize the risk that a valid access token is stolen on a public client, you reduce the token lifetime as a security measure.
In summary, an OIDC access token is nothing but an OAuth2 access token. Setting the length of its lifetime is just a security measure depending on the scenario in which the OAuth2 client runs.
I hope I have answered your questions.