LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Token Session
  • Application Session
  • IAS Session

Was this helpful?

  1. Products
  2. Island.is Authentication Service

Session Lifecycle

PreviousAuthorising API EndpointsNextScopes and Tokens

Last updated 8 months ago

Was this helpful?

When users sign into applications there are up to 3 sessions to be aware of. These sessions are independent but this chapter explains some ways to keep them in sync.

Token Session

For applications which use IAS Access Tokens, you need to consider the token lifecycle.

Access Tokens by default last 5 minutes. They can’t be invalidated, so care should be made to protect access tokens and remove them as soon as the user logs out.

With Refresh Tokens your app can get new Access Tokens as they expire. IAS supports both Inactive Lifetime and Absolute Lifetime for Refresh Tokens. These specify how much time can pass between the app refreshing tokens, as well as the total amount of time the app can refresh tokens.

For sensitive applications it makes sense to have the Refresh Token expirations fairly short (eg 30 minutes inactive, 8 hours absolute). For native applications or less sensitive applications these can be longer (weeks or months).

See for more explanation of absolute and inactive lifetimes.

Default Recommended Refresh Token Lifetimes

web
native

Inactivity Lifetime

20 minutes

90 days

Absolute Lifetime

8 hours

1 year

machine clients SHALL NOT use refresh token, as they MUST request new access token using their clientId and secret, when it expires.

When the user logs out of your application, you should revoke the refresh tokens using IAS’s so the refresh tokens can’t be used again. The endpoint is listed in the document.

If a token refresh fails, it indicates that the Refresh Token has expired, been revoked or used elsewhere (stolen refresh token). In this case you should sign the user out of your application immediately.

Application Session

Many application frameworks have their own session system, i.e. using cookies. These sessions have their own lifecycles separate from Tokens and IAS.

If your application logic depends on IAS Access Token, then you may want to configure your Application Session to outlive the Token Session and/or sync the two:

  • If the user signs out, clear your application session in addition to revoking the Refresh Token.

  • If the Token Session expires, then clear your Application Session cookie before signing the user out.

IAS Session

IAS has its own session which provides a Single Sign-On experience so the user can quickly authenticate to different clients. The IAS Session lasts for 60 minutes after each authentication but no longer than 8 hours.

This means that if you link your user to another application which uses IAS, and it’s been less than 60 minutes since they first logged in, they won’t need to authenticate again. They’ll immediately be authenticated to the second application. Then if they go back to your application or a third application within 60 minutes of that, they still won’t see a sign-in screen.

Even though the user signs out of another application and ends the IAS Session, your application might still have a valid Token Session for some time. IAS does not guarantee single sign-out.

If you wish to force a re-authentication from your users you can use the prompt=login parameter. You can then use the auth_time claim to verify that the authentication used to generate the token is indeed fresh. You can read more about forcing re-authentication

If the user logs out of your application, you SHOULD perform an to terminate the IAS Session.

However, if your application has server-stored sessions, you CAN implement to clear your Application Session and/or Token Session when another application terminates the IDS Session. is unfortunately not available because modern browsers .

here
RP Initiated Logout
Back-Channel logout
Front-Channel logout
block access to third-party content
revocation_endpoint
.well-known/openid-configuration
Refresh Token Expiration