I would agree with Alex. Is SmartSheet SSO-enabled? That could also be a part of it.
The integration, like many of its kind, requires the handshake between systems to be authorized. If you're using native username/password in SmartSheet, the step of having a SmartSheet admin log into their SmartSheet account through the integration window so it obtains a token is key, and is a handshake between ServiceNow and SmartSheet. Quite often, the issue is that the person on the SmartSheet side doesn't have the rights to access the integration system on their side.
However, depending on your SSO provider, you could also be hitting a session issue. Let's say you are a user in SmartSheet as well and are signed into your SSO provider (Okta, Google, etc) to access all your normal apps in a day. You then do a screen-share with the SmartSheet admin and they log in using their SSO credentials. Some systems require you to log out of your current SSO session to create a new one, which then affects other apps you were logged into (like ServiceNow). This session discrepancy then causes the redirect back to the admin resources in ServiceNow to be forbidden (403) because the SmartSheet Admin is not allowed to access the integration parts of ServiceNow.
For this reason, I have normally had SmartSheet System Admin role owners turn on username/password for system admins only (a setting in SmartSheet security settings) so they don't need SSO to log in. This allows your ServiceNow session to stay in place while they log in manually using a SmartSheet-native username/password.
Alternately, you can give the SmartSheet admin the sam_integrator role in ServiceNow temporarily so they are setting up the integration in their profile.
If you are admin in both systems, that's a different story. That would mean your session is the target session in both systems and the handshake should work. At that point, the tickets with each supplier will be better time spent.
