A cláusula AUTHID CURRENT_USER em procedimentos, funções e pacotes PL/SQL é essencial pra controlar o acesso a dados e a execução de código.
Neste artigo vou comparar AUTHID CURRENT_USER com AUTHID DEFINER, explicar onde cada um faz mais sentido, trazer exemplos práticos e listar problemas comuns que podem aparecer.
Muita gente se enrola quando bate de frente com um erro de privilégio ligado ao AUTHID CURRENT_USER.
o que é AUTHID em PL/SQL?
A cláusula AUTHID define de quem são os privilégios usados quando um código PL/SQL roda. Temos duas opções:
- AUTHID DEFINER (padrão)
O código roda com os privilégios do dono do objeto (o criador do pacote, procedure ou função).
Mesmo que o usuário chamador não tenha privilégios, o código acessa as tabelas porque pega do dono do objeto. - AUTHID CURRENT_USER
Aqui quem manda é o usuário que chamou o código. O acesso só acomntece se o usuário tiver privilégios diretos. Além disso, a resolução de nomes (quando você não qualifica o esquema) acontece no schema do chamador.
1. comportamento padrão (AUTHID DEFINER)
SQL>
CREATE OR REPLACE PACKAGE sh.customer_pkg AS
PROCEDURE get_customer(p_cust_id IN NUMBER);
END customer_pkg;
/
Package created.
CREATE OR REPLACE PACKAGE BODY sh.customer_pkg AS
PROCEDURE get_customer(p_cust_id IN NUMBER) IS
v_name VARCHAR2(100);
BEGIN
SELECT cust_first_name || ' ' || cust_last_name
INTO v_name
FROM sh.customers
WHERE cust_id = p_cust_id;
DBMS_OUTPUT.PUT_LINE('Cliente: ' || v_name);
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('Cliente não encontrado.');
END;
END customer_pkg;
/
Package body created.
GRANT EXECUTE ON sh.customer_pkg TO pm;
Grant succeeded.
SQL>
2. executar com o usuário PM (AUTHID DEFINER)

Funciona normalmente, mesmo que o PM não tenha SELECT direto na tabela sh.customers
, porque o pacote roda com os privilégios do dono (SH).
3. alterar o pacote para AUTHID CURRENT_USER
SQL>
CREATE OR REPLACE PACKAGE sh.customer_pkg AUTHID CURRENT_USER AS
PROCEDURE get_customer(p_cust_id IN NUMBER);
END customer_pkg;
/
Package created.
CREATE OR REPLACE PACKAGE BODY sh.customer_pkg AS
PROCEDURE get_customer(p_cust_id IN NUMBER) IS
v_name VARCHAR2(100);
BEGIN
SELECT cust_first_name || ' ' || cust_last_name
INTO v_name
FROM sh.customers
WHERE cust_id = p_cust_id;
DBMS_OUTPUT.PUT_LINE('Cliente: ' || v_name);
EXCEPTION
WHEN NO_DATA_FOUND THEN
DBMS_OUTPUT.PUT_LINE('Cliente não encontrado.');
END;
END customer_pkg;
/
Package body created.
SQL>
4. executar novamente com o usuário PM (AUTHID CURRENT_USER)

O erro ORA-00942: table or view does not exist acontece porque o usuário PM não tem privilégio direto na tabela SH.CUSTOMERS
.
5. conceder privilégios diretos

Agora funciona, #BóBó
principais conclusões
- AUTHID DEFINER (padrão): código sempre executa com os privilégios do dono.
- AUTHID CURRENT_USER: código executa com os privilégios de quem chamou.
- sinônimo não é privilégio: só encurta o nome, mas não libera acesso.
- grants explícitos são obrigatórios: usuários precisam de acesso direto aos objetos.
- escolha estratégica: use DEFINER quando quiser encapsular, e CURRENT_USER quando precisar respeitar os privilégios do usuário final.
O AUTHID CURRENT_USER aumenta segurança e controle em PL/SQL, mas exige cuidado com privilégios. Dominar esse conceito é diferencial pra qualquer DBA ou dev Oracle.
e zas
#20250921 #DBASobrinho #GuinaNãoTinhaDó #BóBó #CaceteDeAgulha #OracleACE