smart-sso keeps a TGT cookie and calls it single sign-on

One jar, one command, and a database that disappears

The fastest path to a running system is three commands, and it needs no database, no Redis and no external service:

git clone https://github.com/a466350665/smart-sso.git
cd smart-sso
mvn -DskipTests package
java -jar smart-sso-server/target/smart-sso-server-2.0.1.jar

Then you open http://localhost:8080 and sign in as admin with the password 123456. The default active profile is dev, which uses an in-memory H2 database and runs smart-sso-server/src/main/resources/db/smart-sso.sql at startup to create the tables and seed demo data for applications, organisations, roles, permissions and users. The README states the consequence plainly: the data exists only for the lifetime of the process and a restart returns everything to the initial state. That is what makes it useful for demos, integration work and automated tests, and it is also why nobody should evaluate the product on the demo data alone. There is a client sample in the same repository, smart-sso-demo, which listens on port 8082 and passes its token in a request header rather than a cookie.

The prod profile deliberately refuses to create the schema

Production runs on MySQL 5.7 or 8.0, and the setup is deliberately manual. You create the database and import the same SQL file, which the README notes is a cross-database script that works on MySQL and H2 alike, and then you edit the connection details in application-prod.yaml before starting the jar with the prod profile. The reason for the manual step is stated in a note rather than left implicit: the prod profile does not execute the database script automatically, because Spring Boot by default only runs initialisation against embedded databases, and the project is avoiding the risk of dropping data. That is a small design decision with a large effect on how safely you can deploy. The one thing to be careful about is the credential in the sample repository: admin and 123456 exist in the seeded data, so change them before the server is reachable by anyone else. The rest of the configuration lives in docs/configuration.md, with the quick reference being the TGT timeout, the accessToken timeout, the sso_ table prefix and the active profile.

The TGT cookie is the session, and the naming is CAS

The protocol is the OAuth2 authorization code flow, and the vocabulary is not. The server maintains a global session called TGT, stored in a cookie whose default name is TGC, and the client validates an accessToken locally while a refreshToken handles renewal. That TGT and TGC naming, and the login endpoint shape the sequence diagram shows as a redirect to /sso/login?clientId=A, are the terminology of CAS, the single sign-on system from a decade earlier, wrapped around a modern token exchange. The flow itself is straightforward. A user hits a protected resource in application A, gets redirected to the authentication centre, signs in once, and the centre creates the TGT and writes the TGC cookie before redirecting back with a code. Application A exchanges the code for tokens and permissions. The part worth noting is the two-level validation the README describes: the authorization code stage checks who the user is, and the token exchange stage checks who the client is, through the clientId and clientSecret, which is what stops one application from exchanging a code for another application's resources.

Single logout is implicit, and that is its weakest assumption

Log out of one application and every other application is supposed to log out too. The mechanism is not a standard back-channel logout. The README describes it as the client implicitly reporting its own logout address when it fetches a token, and the server then remotely notifying all known clients to clear their local tokens. The same callback path carries the second feature, forced offline, where an administrator terminates a specific user's session, the server revokes the credentials immediately and calls back every related client to drop the local session. It works, and it is the feature most Java SSO centres in this class offer, but the design has an assumption worth naming: the server can only reach a client that reported an address, and only if that client is up and willing to honour the callback. A client that crashes, sits behind a firewall, or was never registered cannot be logged out remotely, and the local token it holds stays valid until it expires. The client integration guide is where the details of that contract are written down, along with the no-cookie mode and cross-origin cases.

Button-level permissions match URIs and allow by default

The permission model is deliberately simple and has a consequence you should plan for. Permissions are registered in the permission management screen as URLs, split into menu permissions and button permissions, and a request is controlled when its path matches sso_permission.url exactly. Authorisation can also be isolated per application. The consequence is in the sentence that follows: paths that are not registered are let through. So a controller you add next quarter, with no row in the permission table, is publicly accessible to any authenticated user until someone notices. That is a workable model for a small internal estate where a handful of people hold the register, and a dangerous one for anything larger. The two ways to live with it are to register every protected path as part of code review, and to keep the exclude-urls list in the client configuration as narrow as possible, since that list is the other place where access is granted without a login.

Refresh extends the server stub as well as the client token

Automatic renewal is described as invisible to the user: when the accessToken expires, the client backend calls refreshToken itself, and in the same step extends the lifetime of the credential stub the server holds. That second half is the part most implementations skip and the part that matters for sessions, because a client that can renew forever while the server record expires will log users out at an arbitrary moment, and a server record that never expires turns a refresh token into a permanent credential. The defaults are in the configuration table, with a global TGT session timeout of 7200 seconds and an accessToken timeout of 1800 seconds, so the short-lived token is refreshed inside a two-hour session by default. Other keys documented in the configuration reference are the code timeout, the cookie name, the logout path and the URL patterns. If your session policy differs, these are the numbers to change first, and they are per-application, so two clients can hold different policies from the same server.

Client integration is a starter and four configuration keys

On the client side the claim is three steps: add smart-sso-starter-client, set the smart.sso.* properties, and let the starter's auto-configuration install the filter that does interception and redirect. The minimal configuration is four keys:

smart:
  sso:
    server-url: http://localhost:8080   # required for a standalone client
    client-id: 1000
    client-secret: xxxxxxxx
    exclude-urls: /static/*,/auth/*

The exclude-urls list is the paths that need no login, and a value ending in /* is a prefix match, so /static/* covers a whole tree. The most interesting default is the empty server-url. The README calls this same-origin operation: if the application is also the server, leaving it blank makes page redirects use relative paths and server-to-server calls use a locally derived address. A standalone client that leaves it blank fails to start, and the README is explicit that this is on purpose, because a silent wrong redirect is worse than a failed boot. The clientId and clientSecret come from the application management screen on the server, which is also where the per-application permission isolation is administered.

master is 2.0.x, the only release tag is 1.6.0

The maintenance picture needs reading carefully. The badge says Spring Boot 3.5.9, the requirements are JDK 17 and Maven 3.8, the branch table says master carries Spring Boot 3.5.x on JDK 17 at version 2.0.x, and the quick start runs a jar named 2.0.1. The release history on the other hand lists exactly one GitHub release, 1.6.0, from 2024-07-11, and there is a separate 1.7 branch kept for Spring Boot 2.x on JDK 8. The last push to master was 2026-09-25, so the work is current, but you are deploying from master rather than from a tag, which for an authentication centre is a decision to make consciously. The licence is MIT, and the server, demo, starter base, client, client-redis, server and server-redis modules all live in one Maven reactor, with a verify module holding interface and browser end-to-end tests. Against a full identity provider such as Keycloak, the difference is scope: this is a small centre with its own admin console and no identity federation. Against a library such as Sa-Token, the difference is that permissions live in a database and are shared across applications rather than living in your own code.

Editorial conclusion

Adopt smart-sso if you run a handful of internal Spring Boot applications, you want one place to hold users, roles and menu permissions, and you would rather not run an identity provider. Do not adopt it if you need federation with external identity providers, standards beyond the documented OAuth2 code flow, or a permission model that fails closed, because permissions are matched by URI and unregistered paths are allowed. Verify five things: that every protected path is registered in the permission table before you ship, that the client secret registered in application management matches your starter configuration, that your client sets smart.sso.server-url explicitly rather than relying on the same-origin default, that the TGT timeout of 7200 seconds and the accessToken timeout of 1800 seconds suit your session policy, and which version you are actually deploying, since master is 2.0.x while the only GitHub release is 1.6.0 from 2024-07-11 and the last push was 2026-09-25.

Frequently asked questions

Official sources

1. a466350665/smart-sso on GitHub
2. Issues
3. License: MIT
4. README
5. Releases