Sydney's #1 WordPress Developer - Phone: (02) 8316 8801
One login, every system.
If your staff log into Microsoft 365, Google Workspace, or Okta to do their jobs, they should not need a separate account for your custom portal or application. We integrate authentication so your staff use the credentials they already have, and access is managed centrally by your IT team.
If your staff log into Microsoft 365, Google Workspace, or Okta to do their jobs, they should not need a separate username and password for your custom portal or application. We integrate authentication into custom web applications and portals so your staff log in once with the credentials they already have, and access is managed centrally by your IT team rather than inside each application separately.
When someone joins the organisation, their access to connected applications is part of the same process as creating their corporate account. When they leave and their account is disabled, they lose access everywhere at once. No manual cleanup. No forgotten accounts sitting active after someone has departed.
Partnering with Code and Visual gives you access to:
Organisations accumulate custom applications over time. A staff portal here. An administration interface there. A reporting tool for a specific business unit. Each system has its own user database, its own login screen, and its own credentials your staff have to manage and your IT team has to maintain. When someone joins, accounts need to be created separately in each system. When they leave, each system has to be updated. The process is slow, error-prone, and regularly leaves former employees with active access longer than it should.
SSO integration eliminates the separate credential problem. Your custom application delegates authentication to the identity system your organisation already manages. Staff use the credentials they already know. Your IT team manages access from one place. The security policies your identity provider already enforces, including multi-factor authentication and session timeouts, apply to your custom application without any additional configuration inside it.
Where SSO integration with an external identity provider is not appropriate, we build custom authentication systems with the same discipline: secure credential handling, role-based access control, and documentation that lets your team operate and extend the system without needing the original developer in the room.
Code and Visual's Australian-based team implements authentication integrations that connect to your existing identity provider, map to your organisation's role structure, and ship with the documentation your IT and security teams need to manage and extend the connection independently from day one.
The following projects demonstrate authentication and access control built as part of custom application and portal builds, where secure user identity and role-based data access were core requirements of the system.
Royal Australian and New Zealand College of Obstetricians and Gynaecologists (Audit App)
Donaldson Australasia (Truck Filter Guide Administration Portal)
One login:
Your staff use the credentials they already have. Access is managed in one place. Departing employees lose access the moment their corporate account is disabled.
Connect to the identity system you already have
Most organisations running Microsoft 365, Google Workspace, or a dedicated identity platform like Okta or Azure Active Directory already have a single system that knows who your staff are and what they are authorised to do. When a new staff member joins, their account is created there. When someone leaves, it is disabled there. The problem arises when a custom-built portal or application runs its own separate user database with no connection to that system.
We integrate custom web applications and portals with your existing identity provider using OAuth 2.0 and OpenID Connect for modern providers, or SAML 2.0 where required for enterprise compatibility. Your staff log in with the credentials they already use, through a login flow that respects your organisation's existing policies including any multi-factor authentication your identity provider enforces.
Where SSO is not required and a custom authentication layer better suits the application, we build that too, with the same attention to secure credential handling, session management, and role-based access control.
What this gives you:
Roles managed where you already manage them
Authentication confirms who a user is. Authorisation determines what they can do. For organisations with an existing identity provider, both decisions should be managed there, not duplicated inside every custom application.
We map your identity provider's groups to permission levels inside the custom application. A user in your "Finance Managers" group in Azure Active Directory can access the finance section of your portal. A user in a read-only group cannot update records. When someone's role changes in the identity provider, the change takes effect in the application without any additional administration in the application itself.
For applications that do not connect to a corporate identity provider, we implement role-based access control within the custom authentication layer using the same principle: permissions are defined in one place and enforced consistently throughout the application.
What this looks like in practice:
Documented for your IT and security teams
Authentication integrations have a longer operational life than most features. They touch security boundaries, involve credential and token handling, and need to be understood by people who were not part of the original build: your internal IT team, your security reviewers, and the developers who will maintain the codebase after handover.
Every authentication integration we deliver is documented at two levels. The operational documentation covers what your IT team needs to manage the connection: how credentials are rotated, how to add the application to a new identity provider registration, and how to diagnose a login failure without developer involvement. The developer documentation covers the implementation: the token flow, the role and claim mappings, the session handling approach, and any assumptions made about the identity provider configuration.
Post-launch support is scoped explicitly. If your organisation changes identity providers or updates its SSO configuration, we document what that will require from the application side so the transition can be planned rather than improvised.
What handover looks like:
If Your Staff Need a Separate Login for Every System, That Is the Problem We Fix.
Sydney CBD -