Understanding Proxy Credentials
A Proxy Credential is a username and password that an application uses to authenticate a SOCKS5 connection through MyOwnProxy. It is separate from a user's MyOwnProxy sign-in and from temporary SSH access to a Node.
Applications combine a Proxy Credential with the host and port for a Pool or direct Node connection. See Using the Proxy for application connection guidance.
Credential types and scope
MyOwnProxy provides two types of Proxy Credential:
| Type | Scope | Intended use | Expiration | Current endpoint access |
|---|---|---|---|---|
| Temporary | One selected Gateway | Short tests and debugging | Required and automatic; the generated result shows the exact lifetime and expiration time | Pool entry points on the selected Gateway |
| Persistent | The Customer | Ongoing application and integration access | Optional; without an expiration time, it remains active until revoked | Pool and direct Node entry points on the Customer's applicable Gateways |
A Gateway-scoped temporary credential cannot be used through another Gateway. A Customer-scoped persistent credential is made available to the Customer's Gateways, so an application can use the same username and password at applicable Gateway proxy endpoints after the credential has propagated.
Scope does not guarantee that an endpoint is operational. The selected Gateway, Proxy, Pool, and Node path must still be correctly configured and available.
Credentials are independent resources
A Proxy Credential is not owned by an individual Proxy, Pool, or Node. Its lifecycle is managed separately:
- Deleting a Proxy does not revoke a credential.
- Removing or replacing a Node does not revoke a credential or require a new one.
- A persistent credential can continue to authenticate at other applicable Customer Gateway endpoints.
- A temporary credential remains limited to the Gateway that generated it and expires automatically.
Revoke persistent credentials separately when access must end. The current customer interface cannot rotate, revoke, or otherwise invalidate a temporary credential before its automatic expiration. Do not use a temporary credential when the ability to end access early is required.
Credential lifecycle
Persistent credentials have these customer-visible states:
| State | Meaning |
|---|---|
| Active | The credential can authenticate at endpoints within its scope, subject to propagation and endpoint availability. |
| Expired | Its configured expiration time has passed. New authentication attempts are rejected. |
| Revoked | An ADMIN ended its validity. New authentication attempts are rejected after the change propagates. |
Rotating an active persistent credential replaces its password. Its name, username, credential ID, endpoint scope, and expiration time stay the same. Rotation does not create a second credential and does not provide an overlap period for the old and new passwords.
Temporary credentials do not have a managed status list. Each one is generated with a mandatory lifetime and expiration time. After it expires, it can no longer be used to authenticate new SOCKS5 connections.
Secret visibility
MyOwnProxy shows a credential password only once:
- A persistent password is shown when the credential is created and the replacement password is shown when it is rotated.
- A temporary password is shown in the generation result.
- After the result is closed, the password cannot be viewed or retrieved again.
The persistent-credential list continues to show non-secret information such as the name, credential ID, username, status, expiration, and creation and update times. Temporary credentials are not added to that list and cannot be reopened after the generation result is closed.
Store every password in an approved secret manager before closing the result. If a persistent password is lost, rotate it. If a temporary password is lost, generate another temporary credential.
New and established connections
MyOwnProxy checks a Proxy Credential when a new SOCKS5 connection is established. Expiration, rotation, and revocation therefore determine whether new authentication attempts succeed.
MyOwnProxy does not provide a customer-visible guarantee that these lifecycle events immediately terminate a connection that is already established. Use a new connection when verifying a credential change. If access must stop urgently, also stop the application or close its existing connections rather than relying only on credential revocation.
Choosing a credential type
Use a temporary credential when you need short-lived Pool access through one Gateway for testing or debugging. Its automatic expiration limits how long the generated secret remains useful.
Use a persistent credential for an application or integration that needs ongoing access, access through more than one Customer Gateway, or direct Node access. Give independent applications separate persistent credentials when you need to rotate or revoke one without changing the others.
See Managing Proxy Credentials for the current customer workflow, secret-handling guidance, and verification procedure.