Developer guide

An administrator invites you to one of your company's tenants. Your account covers that tenant's applications and, automatically, its sandbox twin: the test-mode copy where you build and test before anything goes live. It is a separate sign-in from the administrators' panel, and it never gives you administrator access.

Everything you change is recorded in an audit trail that administrators can read, with your name on it.

The invitation. An administrator invites your email address from your tenant's page. You get an email with a one-time link, valid for 72 hours. Open it, enter your name and choose a password (at least 12 characters, checked against known data breaches). The link works once. Choosing a password does not sign you in by itself: OneLogin emails you the 6-digit code straight away and shows the code screen, so you enter the code from your inbox and you are in (you do not retype your email or password). An expired or used link needs a new invitation from an administrator.

Every sign-in is two steps. At the developer sign-in page, enter your email and password; then enter the 6-digit code emailed to you. The code expires after 10 minutes and allows 5 attempts. The code is asked for every time: there is no “remember this device”, because this account can change redirect addresses and credentials.

• You are signed out after 30 minutes without activity, and after 8 hours in total.
• Repeated wrong passwords or codes lock the account for a while, and you are emailed when that happens.
• There is no “Forgot password” link on purpose. If you lose your password, an administrator sends you a reset link (valid 60 minutes). Resetting your password signs you out of every session, and, like a new account, ends at the code screen: the link never signs you in on its own.
• An administrator can disable your account; you are signed out on your next click, and the account and its history are kept.
• One email address is one account on one tenant. If you work for two companies' tenants, ask for an invitation to each at a different address.

Keep your password and your sign-in codes to yourself. Nobody from OneLogin will ask for them, and you should not paste them into a chat with an AI assistant.

Sandbox tenants never deliver email or text messages: sign-up and sign-in messages from your test applications are captured instead. The Sandbox inbox page of the portal shows them, newest first, so you can read the verification and sign-in codes your test users are sent (use made-up addresses). Codes expire 10 minutes after they are sent and allow 5 attempts. The page does not update by itself: use Refresh. You can search by recipient or subject.

The inbox shows everything captured for your sandbox tenant, to everyone on your team who has an account, so treat it as shared. Only your own team's sandbox mail is ever shown. (Administrators can also hand out a separate private inbox link to a tester who has no account. You do not need one once you have portal access.)

A redirect URI is where OneLogin may send a user back after sign-in. It is matched exactly (scheme, host, port and path), and there are no wildcards. On a sandbox application you add and remove them yourself, one address at a time. Every change asks for your portal password.

• localhost and 127.0.0.1 on any port are always allowed, and so is any host ending in .test or .localhost (for example redeem.test), whether you use http:// or https://: for example http://localhost:3000/callback. Prefer localhost or a .localhost host: a browser sends those to your own machine and nowhere else. A .test name is reserved and never in public DNS, but your own machine's DNS is what resolves it, so give it a hosts-file entry (for example 127.0.0.1 redeem.test) rather than leaving it to resolve on its own. No approval is needed.
• The scheme and host are saved in lower case, and one trailing dot on the host is dropped, because that is how your application sends them back; the path and query are kept exactly as you typed them.
• An https:// address (for example your team's staging site) is allowed only on an approved origin: the scheme, host and port that an administrator has approved for that application, once. The application page lists what is approved; if your staging origin is not there, ask an administrator to approve it. Once it is, any path on it can be added by you.
• Any other http:// address (one that is not localhost, 127.0.0.1 or a .test / .localhost host) is refused. So is an address with a fragment (#), a username or password in it, or OneLogin's own address.
• At most 20 redirect URIs per application and 20 changes an hour (a change that is refused does not count).
• One address is reserved for administrators' own test runs. It is listed with a Reserved label and cannot be removed.

Changes take effect immediately. No email is sent for sandbox changes: the audit trail is the record.

A confidential application has a client secret; a public one has none, so there is nothing to rotate. To rotate a sandbox secret, open the application, choose how long the old secret keeps working, enter your portal password and confirm. The choices are: now (the old secret stops at once, so use this if it may have leaked), 1 hour, 24 hours (the default), 3 days or 7 days. The overlap lets you update every server without downtime.

• The new secret is shown once, on the page you land on. Copy it into your server configuration straight away: it cannot be shown again, and reloading the page does not rotate it a second time. If you lose it, rotate again.
• The application page shows until when the previous secret is still accepted. Leave it to expire once every server has the new one. An administrator can end it early.
• At most 5 rotations an hour. Each is recorded in the audit trail; no email is sent for a sandbox rotation.
• The secret goes into your server's configuration only: never into browser code, a repository, a URL or a log.

A live redirect URI decides where real users' sign-in codes are sent, so on a live application you cannot change the list yourself. You send a request, and an administrator approves or rejects it. Until they approve, nothing changes.

1. Open the live application and use Request a change: choose add or remove, enter the one exact address and your portal password. Only https:// addresses are accepted, with no fragment, no username or password in the address, no wildcards and no spaces, and never OneLogin's own address. One address per request.
2. Every full administrator is emailed. Your request appears in Your requests on the application page as pending. Your team can have at most 10 open requests per application.
3. An administrator approves it (with their own password) or rejects it, optionally with a short note. You are emailed the decision, and a rejection's note is shown on the application page.
4. An approved change is applied at once. If the address was already registered (or a removal was already done), the request simply closes as approved and says nothing changed.

• A request nobody decides lapses after 14 days. Send it again if you still need it.
• You can cancel your own pending request from the application page.
• Removing an address is not the same as revoking access. Sign-in codes already issued stay valid for up to 10 minutes and tokens already issued keep working. To cut an application off at once, ask an administrator to suspend it.

By default an administrator rotates a live application's secret and hands it to you over a private channel; the portal then offers no rotate button for a live application, only a note to ask your administrator. An administrator can switch on live rotation by developers for your tenant. Only then does the live application page offer it.

1. Password and window. Pick how long the old secret keeps working (the same choices as in the sandbox, including now, which cuts your live application off until it has the new secret), enter your portal password and press Email me a confirmation code. Nothing is rotated yet.
2. Emailed code. Enter the 6-digit code we email you (it expires after 10 minutes, allows 5 tries and works once). Only then is the secret rotated and shown to you once.

• Every full administrator is emailed the moment a live secret is rotated (the application, who did it and when the old secret stops working, never the secret), and the rotation is recorded in the audit trail. If it was not you, tell an administrator at once.
• If an administrator switches live rotation off while you are part-way through, the rotation will not complete. A suspended application cannot be rotated.
• Rotation is limited to 5 an hour, and asking for a code to be emailed is limited to 3 every 10 minutes.

These limits are deliberate: those actions simply do not exist for a developer account, whatever you click. For any of them, ask an administrator.

• Create, delete or suspend applications or tenants, or change an application's name, type, first-party setting or status.
• Change a live application's redirect URIs without an administrator's approval.
• See any other tenant's applications, or any list of end users or their personal details. The only user-facing data you see is your own sandbox's captured test mail.
• Read a client secret at any other time than the one-time reveal right after you rotate it.
• Invite colleagues or reset anyone's password: administrators do that.
• Use the administrators' panel, or an API: the portal is a web page for people, with no tokens or scripts to automate it.

Working with an AI coding assistant? Do not give it your portal password or codes. Give it the values it needs (the client ID and the redirect URI) and point it at the agent brief, which tells it to ask you first.

• No sign-in code arrives. Check your spam folder, wait a minute and sign in again for a fresh code (an older code stops working). If mail never arrives, tell an administrator.
• Locked out. Wait a while and try again with the right details. A password you cannot remember needs a reset link from an administrator.
• A redirect address is refused. The message says why. The usual causes are an https origin that is not approved yet, an http:// address that is not a local development host, a wildcard, or the per-application limit.
• Sign-in itself fails in your application. That is an integration question: see the integration guide error reference.